From nobody Sun Mar 1 02:13:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026F61A8895 for ; Sun, 1 Mar 2015 02:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.152 X-Spam-Level: X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 vQSA8_X-h_ik for ; Sun, 1 Mar 2015 02:13:35 -0800 (PST) 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 906931A1B85 for ; Sun, 1 Mar 2015 02:13:35 -0800 (PST) Received: from [79.253.34.96] (helo=[192.168.71.100]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YS0sJ-00082H-Nr; Sun, 01 Mar 2015 11:13:27 +0100 Message-ID: <54F2E645.8030003@lodderstedt.net> Date: Sun, 01 Mar 2015 11:13:25 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: RFC Errata System , mark.mcgloin@ie.ibm.com, phil.hunt@yahoo.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com References: <20150209201010.C43A6180092@rfc-editor.org> In-Reply-To: <20150209201010.C43A6180092@rfc-editor.org> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: david.gladstone@nib.co.nz, oauth@ietf.org Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6819 (4267) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 10:13:38 -0000 Hi all, @David: Thanks for reporting this issue. Mark, Phil and I discussed the errata and came to the following conclusion: The introduction is correct because this section is about "DoS Attacks That Exhaust Resources" caused by the fact that the AS creates a nontrivial amount of entropy for every token. BUT one recommended counter-measure is - The authorization server should include a nontrivial amount of entropy in authorization "codes" which definitely does not make sense because it recommends to do what the AS already does (and what enables this attack angle). Our recommendation as authors is to remove this bullet. kind regards, Torsten. Am 09.02.2015 um 21:10 schrieb RFC Errata System: > The following errata report has been submitted for RFC6819, > "OAuth 2.0 Threat Model and Security Considerations". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6819&eid=4267 > > -------------------------------------- > Type: Editorial > Reported by: David Gladstone > > Section: 4.4.1.11 > > Original Text > ------------- > If an authorization server includes a nontrivial amount of entropy > > Corrected Text > -------------- > If an authorization server includes a trivial amount of entropy > > Notes > ----- > The threat being described outlines a scenario where too little entropy is involved; countermeasures include using non-trivial amounts of entropy. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6819 (draft-ietf-oauth-v2-threatmodel-08) > -------------------------------------- > Title : OAuth 2.0 Threat Model and Security Considerations > Publication Date : January 2013 > Author(s) : T. Lodderstedt, Ed., M. McGloin, P. Hunt > Category : INFORMATIONAL > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > From nobody Mon Mar 2 07:14:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C921A8881 for ; Mon, 2 Mar 2015 07:14:17 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 blPfkZlBsYzJ for ; Mon, 2 Mar 2015 07:14:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A116E1A88EB for ; Mon, 2 Mar 2015 07:06:14 -0800 (PST) Received: from [192.168.131.138] ([80.92.121.102]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MC4y8-1YJcDU2SFU-008rjK for ; Mon, 02 Mar 2015 16:06:12 +0100 Message-ID: <54F47C62.40606@gmx.net> Date: Mon, 02 Mar 2015 16:06:10 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QOJ4q717EcK8rpjdx3nkNbqpCVdSIb5mE" X-Provags-ID: V03:K0:NBKPgXppO0AzIN5fvhAx7/95ZwFF+c53kQhhup+2lb7uq5xs4Xp TRxJQbyk4rr+oNiJaKOj2nb4u6JHCMuYzR0y3JH7rcaD2xjpixtSAHJkrxqImt06GQfIPkG Rjx1FkxJPq9MPFll91Elzv1Yi8dqs9Y73HQnqpBHTF+HdekvPyuuJhpuFgVDWFwZkgZA+QJ JnP4BE+MJHTPV8j/gsGAg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Shepherd Write-Up for Dyn-Reg updated X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 15:14:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QOJ4q717EcK8rpjdx3nkNbqpCVdSIb5mE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I have updated the shepherd write-up for version 24 of the dynamic client registration protocol. The update concerned the clarification of the copyright situation initially raised with this mail: http://www.ietf.org/mail-archive/web/oauth/current/msg13322.html It turned out that it was better to reach out to the IETF Trust (instead of sending a mail to Jorge and Scott), which is what Kathleen did. The discussions concluded that RFC 5378 requires the contributor to assure the IETF that it has all necessary rights to make the contribution, and the IETF relies on that assurance in permitting all contributions to be made. This is what John did in his mail to the list: http://www.ietf.org/mail-archive/web/oauth/current/msg14250.html Since document updates following discussions with Kathleen also had a positive impact on my earlier concerns I removed the issues I had with the document from the shepherd write-up as well. The most recent version of the shepherd write-up can be found at: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/= Ciao Hannes --QOJ4q717EcK8rpjdx3nkNbqpCVdSIb5mE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9HxjAAoJEGhJURNOOiAtbVoH/0CoxRa7Zy1HDgu4GoQ7s3BJ ewoGPoQ3+92vyAayQxbiHVmPzJhP6lMbkWpxd1+mtMJlLcSKytr/AXWSChx39K5z gbenrLo7F+cKPotTeQIfHURU7/aydr88hqXeuHAEL/BRwHarCxxWhum3CWuWg5Eh v+PUp1i1HbsYRof1H4G8Ze5Br0lMXind+GQ/N+2HYt9oadMjOhSfPGc0nqQjSIU4 XIs8IyUhZB7ciqKW0FlXR3jXaBGuXSRErYgt/rIO0OuqiFNffE2Sp3I96CmBCGEr bcToOa15rLZmTPooBSRpjIVf+f9oIHUj0moD5zTZbUadjZAwIzYVrWA96b7Bhag= =kBKL -----END PGP SIGNATURE----- --QOJ4q717EcK8rpjdx3nkNbqpCVdSIb5mE-- From nobody Mon Mar 2 07:31:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE091A1AA9 for ; Mon, 2 Mar 2015 07:31:26 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ajiwex4YgFIg for ; Mon, 2 Mar 2015 07:31:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EAF1A01FC for ; Mon, 2 Mar 2015 07:31:24 -0800 (PST) Received: from [192.168.131.138] ([80.92.121.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDW9x-1YGhHj1ISr-00GprF for ; Mon, 02 Mar 2015 16:31:22 +0100 Message-ID: <54F48248.2030706@gmx.net> Date: Mon, 02 Mar 2015 16:31:20 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tVce5Q0bGHkJIWOFRds4uMu2WX74d0mKG" X-Provags-ID: V03:K0:/S3hngQ8irPew9lhgejX3UOtBvwCjfM4V45ZWOFvMT9MDSIg7kn j+I1lcL/ylHUZfyS+W8pshrPZud5KpMA8FHSmrP0QNAzqqnbc7N9aEX6cZRnGlEwkYk8PeM 2wRXDdZKTySmy38ZwuEM5f0lJ/yqH55Qvcd/OH66W+RwR/1yUtQcINQ/Ykt2h9A23pA07MX XSFKDWDTcHOeIP/WVr6sQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-spop-10: Your feedback needed. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 15:31:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tVce5Q0bGHkJIWOFRds4uMu2WX74d0mKG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I am trying to finalize my work on the shepherd write-up of draft-ietf-oauth-spop. Unfortunately, there are still some outstanding issues: 1. S256 as a mandatory-to-implement code challenge method (by the Authorization Server) Currently, S256 is MTI but implementations do not use S256 (yet). Hence, we have very few (maybe not even a single) implementation that is in conformance with the specification at the moment. Does the group see a problem with this choice of MTI (or lack of conformance)? 2. Naveen Agarwal has not provided his confirmation that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Without his confirmation I cannot finalize my shepherd write-up. 3. Normative language regarding code verifier randomness We had a discussion about the language used to describe what implementations need to provide in terms of randomness of the code verifier. Here is the discussion thread: http://www.ietf.org/mail-archive/web/oauth/current/msg14217.html Ultimately, the issue boiled down to the following sentence and the use of 'MUST' vs. 'SHOULD': "the code verifier SHOULD have enough entropy to make it impractical to guess the value" It would be good to know whether the group objects using MUST instead of SHOULD to enhance security. Ciao Hannes --tVce5Q0bGHkJIWOFRds4uMu2WX74d0mKG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9IJIAAoJEGhJURNOOiAtlcgIAJbduCG/rxcDss8t0nsnH3A/ hg5CVY5sN1ZExjxA1BVwjXm2BufP9tsKXJq6/mUMFv2mCrRbDiOONTGSjzhb7Uyz WSLH4EqTgG5HvBj0HiGaw8OGQg4tQ0ZwAPoYnnj4I0XoKA9m6cuh287Lv0CSDJ60 w71W2KZnsawjz5yQXkJQqFzMQTifx9Q8kuUZY7XNqa84esvfIYYgAldn/PAXRIo9 oIOXsRb+SWvaYL9Fz+Q/C9yPBLmkP48i/lbQR+eL8es/sS16heuIieYG/ZTZWPkJ XN3cm9ncpu3vIZce8K2AJZIoLBUcmiHpVpwMbxKZ+PU+LHOdh0jdY9nkdRzhkUQ= =apgG -----END PGP SIGNATURE----- --tVce5Q0bGHkJIWOFRds4uMu2WX74d0mKG-- From nobody Mon Mar 2 07:56:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5271A00E4 for ; Mon, 2 Mar 2015 07:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 8zITGV1Ob_17 for ; Mon, 2 Mar 2015 07:56:54 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::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 84DAF1A00D4 for ; Mon, 2 Mar 2015 07:56:53 -0800 (PST) Received: by lamq1 with SMTP id q1so8074049lam.9 for ; Mon, 02 Mar 2015 07:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F6GXGEHSx/3rjFIRHiUtw0vDTuLeZmIaJpO499HC3Z4=; b=MJYWebuCaJ7FPrSOIF1XJDJUyMhBuBdUIVlLL6mcaNRR0eIoR7M7I7aIhe1csvgHju gdk9sBZx3FJlzPjkh2gdxqHlT9oxhRTQZIlDkib2gP26iv6UQAR5EOKD3qDH6De9EsxD 9VkDzOhqZL6e9FHQcvEJT/PXbgiYBpdeKmtq1k2Y4uUwBMs6lOs1bVaCEIhFZbVDuj3a pq0/awPQZeIH8aMaRtGu4BfwJk0fBMStsoFz4A1ZRXMkWjjRYfi6mL3s/0zYGDG1TiiM BPVKbBkpybd4O9J3Vh2hWDtQWjLLdDAY7klHOhKfuZqbsgwesqm2eNoY0qE3Rs0NfeuC VtHg== MIME-Version: 1.0 X-Received: by 10.112.146.66 with SMTP id ta2mr25513932lbb.0.1425311812007; Mon, 02 Mar 2015 07:56:52 -0800 (PST) Received: by 10.112.167.101 with HTTP; Mon, 2 Mar 2015 07:56:51 -0800 (PST) In-Reply-To: <54F47C62.40606@gmx.net> References: <54F47C62.40606@gmx.net> Date: Mon, 2 Mar 2015 10:56:51 -0500 Message-ID: From: Kathleen Moriarty To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7b3a857c3fbde205105044c0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd Write-Up for Dyn-Reg updated X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 15:56:56 -0000 --047d7b3a857c3fbde205105044c0 Content-Type: text/plain; charset=UTF-8 Thank you, Hannes. I'll do a quick review of changes and if everything looks good, I'll start IETF last call. On Mon, Mar 2, 2015 at 10:06 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > I have updated the shepherd write-up for version 24 of the dynamic > client registration protocol. The update concerned the clarification of > the copyright situation initially raised with this mail: > http://www.ietf.org/mail-archive/web/oauth/current/msg13322.html > > It turned out that it was better to reach out to the IETF Trust (instead > of sending a mail to Jorge and Scott), which is what Kathleen did. The > discussions concluded that RFC 5378 requires the contributor to assure > the IETF that it has all necessary rights to make the contribution, and > the IETF relies on that assurance in permitting all contributions to be > made. This is what John did in his mail to the list: > http://www.ietf.org/mail-archive/web/oauth/current/msg14250.html > > Since document updates following discussions with Kathleen also had a > positive impact on my earlier concerns I removed the issues I had with > the document from the shepherd write-up as well. > > The most recent version of the shepherd write-up can be found at: > http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/ > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Best regards, Kathleen --047d7b3a857c3fbde205105044c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, Hannes. =C2=A0

I'll do a= quick review of changes and if everything looks good, I'll start IETF = last call.

On Mon, Mar 2, 2015 at 10:06 AM, Hannes Tschofenig &= lt;hannes.ts= chofenig@gmx.net> wrote:
Hi= all,

I have updated the shepherd write-up for version 24 of the dynamic
client registration protocol. The update concerned the clarification of
the copyright situation initially raised with this mail:
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 3322.html

It turned out that it was better to reach out to the IETF Trust (instead of sending a mail to Jorge and Scott), which is what Kathleen did. The
discussions concluded that RFC 5378 requires the contributor to assure
the IETF that it has all necessary rights to make the contribution, and
the IETF relies on that assurance in permitting all contributions to be
made. This is what John did in his mail to the list:
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 4250.html

Since document updates following discussions with Kathleen also had a
positive impact on my earlier concerns I removed the issues I had with
the document from the shepherd write-up as well.

The most recent version of the shepherd write-up can be found at:
http://datatracker.ietf.org/doc/draft-ietf-oau= th-dyn-reg/shepherdwriteup/

Ciao
Hannes


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




--

Best regards,
Ka= thleen
--047d7b3a857c3fbde205105044c0-- From nobody Mon Mar 2 08:03:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4171E1A1A72 for ; Mon, 2 Mar 2015 08:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=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 fuy9JdRPaHZ4 for ; Mon, 2 Mar 2015 08:03:36 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::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 05FFD1A1ABB for ; Mon, 2 Mar 2015 08:03:36 -0800 (PST) Received: by labgd6 with SMTP id gd6so31322815lab.7 for ; Mon, 02 Mar 2015 08:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C1dHF4CqBrp48EkGjiDpTEm8W/a0CP9SDYGvgIqieyI=; b=M+L1XBYosfCYBR7gWpIqiGjXWp7ISFJGXS+rjxAlGISFJxnkx/J8/aLtX9T4wvE+v0 zyemkdbGwj8bnQiclE1OWxypFrj6l30rb/dt4wmZ66qwOaGZmZzqHkdfEbwct2QlMCo9 A4t95CfnIWj4ecaAteaKeVNscnWNKzVYpufF0HyjxJVgNWVFSjasH56UChzTQLUeDBrK CxiKswZM4xdfpw8iegFRtA2mNRDN6Acpxo/oUpWALNHFXJLQcOS9zu4hq3X+r314WzIH 4CEgk7ftmAXMoKenGYAMLGlm9oaeNOJvuxajvYiq90K/YxSCoS1CRL/S+LpsIh7AzeZd ZKPw== MIME-Version: 1.0 X-Received: by 10.112.130.39 with SMTP id ob7mr15543200lbb.32.1425312214482; Mon, 02 Mar 2015 08:03:34 -0800 (PST) Received: by 10.112.167.101 with HTTP; Mon, 2 Mar 2015 08:03:34 -0800 (PST) In-Reply-To: References: <54DC2CB1.8090400@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> <54E4D2A5.5030705@gmx.net> Date: Mon, 2 Mar 2015 11:03:34 -0500 Message-ID: From: Kathleen Moriarty To: Justin Richer Content-Type: multipart/alternative; boundary=047d7b3433da3d05310510505c19 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:03:39 -0000 --047d7b3433da3d05310510505c19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you, I just reviewed the diff and the changes to the draft look good. Best regards, Kathleen On Wed, Feb 25, 2015 at 11:23 AM, Justin Richer wrote: > John=E2=80=99s assessment is correct and this is what we=E2=80=99ve tried= to capture in > the privacy considerations section of the latest draft: > > In general, the metadata for a client, such as the client name and > software identifier, are common across all instances of a piece of > client software and therefore pose no privacy issues for end-users. > Client identifiers, on the other hand, are often unique to a specific > instance of a client. For clients such as web sites that are used by > many users, there may not be significant privacy concerns regarding > the client identifier, but for clients such as native applications > that are installed on a single end-user's device, the client > identifier could be uniquely tracked during OAuth 2.0 transactions > and its use tied to that single end-user. However, as the client > software still needs to be authorized by a resource owner through an > OAuth 2.0 authorization grant, this type of tracking can occur > whether or not the client identifier is unique by correlating the > authenticated resource owner with the requesting client identifier. > > Note that clients are forbidden by this specification from creating > their own client identifier. If the client were able to do so, an > individual client instance could be tracked across multiple colluding > authorization servers, leading to privacy and security issues. > Additionally, client identifiers are generally issued uniquely per > registration request, even for the same instance of software. In > this way, an application could marginally improve privacy by > registering multiple times and appearing to be completely separate > applications. However, this technique does incur significant > usability cost in the form of requiring multiple authorizations per > resource owner and is therefore unlikely to be used in practice. > > > Hopefully this is more clear now. > > Thanks for the feedback and close review, > =E2=80=94 Justin > > > On Feb 24, 2015, at 8:55 PM, John Bradley wrote: > > > > Yes but it is authenticating the client to the AS as part of the > resource owners consent. > > > > Ther eis a one to one mapping of resource owner to client in that case. > > > > The client ID is no more identifying than the refresh token that maps t= o > the RO by design. > > > > Yes the grant identifies the RO in some way. The client_id and secret > prevent that from being used in a different client if the bearer token > leaks. > > > > Remember the client_id is going to be different at different AS as each > will have a separate registration. > > If the client_id was fixed across multiple AS then it would be a > correlation issue, but that is not the case. > > > > Perhaps I am not understanding the concern? > > > > John B. > > > >> On Feb 18, 2015, at 12:57 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> > >> Hi Justin, Hi John, > >> > >> I believe that provisioning a client with a unique id (which is what a > >> client id/client secret is) allows some form of linkability. While it > >> may be possible to associate the client to a specific user I could ver= y > >> well imagine that the correlation between activities from a user and > >> those from the client (particularly when the client is running on the > >> user's device) is quite possible. > >> > >> Ciao > >> Hannes > >> > >> On 02/18/2015 06:37 PM, Justin Richer wrote: > >>> I=E2=80=99ll incorporate this feedback into another draft, to be post= ed by the > >>> end of the week. Thanks everyone! > >>> > >>> =E2=80=94 Justin > >>> > >>>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty > >>>> >>>> > wrote: > >>>> > >>>> > >>>> > >>>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley >>>> > wrote: > >>>> > >>>> snip > >>>>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty > >>>>> >>>>> > wrote: > >>>>> > >>>>>> The client_id *could* be short lived, but they usually aren't. I > don't see any particular logging or tracking concerns using a dynamic OAu= th > client above using any other piece of software, ever. As such, I don't > think it requires special calling out here. > >>>>> > >>>>> > >>>>> Help me understand why there should not be text that shows this > >>>>> is not an issue or please propose some text. This is bound to > >>>>> come up in IESG reviews if not addressed up front. > >>>>> > >>>>> > >>>> > >>>> The client_id is used to communicate to the Authorization server > >>>> to get a code or refresh token. Those tokens uniquely identify > >>>> the user from a privacy perspective. > >>>> It is the access tokens that are sent to the RS and those can and > >>>> should be rotated, but the client)id is not sent to the RS in > >>>> OAuth as part of the spec. > >>>> > >>>> If you did rotate the client_id then the AS would track it across > >>>> rotations, so it wouldn=E2=80=99t really achieve anything. > >>>> > >>>> One thing we don=E2=80=99t do is allow the client to specify the > >>>> client_id, that could allow correlation of the client across > >>>> multiple AS and that might be a privacy issue, but we don=E2=80=99= t allow > it. > >>>> > >>>> > >>>> Thanks, John. It may be helpful to add in this explanation unless > >>>> there is some reason not to? > >>>> > >>>> > >>>> John B. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Best regards, > >>>> Kathleen > >>>> _______________________________________________ > >>>> 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 Best regards, Kathleen --047d7b3433da3d05310510505c19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, I just reviewed the diff and the changes to the= draft look good.

Best regards,
Kathleen
=

On Wed, Feb= 25, 2015 at 11:23 AM, Justin Richer <jricher@mit.edu> wrote:<= br>
John=E2=80=99s assessment is correct and = this is what we=E2=80=99ve tried to capture in the privacy considerations s= ection of the latest draft:

=C2=A0 =C2=A0In general, the metadata for a client, such as the client name= and
=C2=A0 =C2=A0software identifier, are common across all instances of a piec= e of
=C2=A0 =C2=A0client software and therefore pose no privacy issues for end-u= sers.
=C2=A0 =C2=A0Client identifiers, on the other hand, are often unique to a s= pecific
=C2=A0 =C2=A0instance of a client.=C2=A0 For clients such as web sites that= are used by
=C2=A0 =C2=A0many users, there may not be significant privacy concerns rega= rding
=C2=A0 =C2=A0the client identifier, but for clients such as native applicat= ions
=C2=A0 =C2=A0that are installed on a single end-user's device, the clie= nt
=C2=A0 =C2=A0identifier could be uniquely tracked during OAuth 2.0 transact= ions
=C2=A0 =C2=A0and its use tied to that single end-user.=C2=A0 However, as th= e client
=C2=A0 =C2=A0software still needs to be authorized by a resource owner thro= ugh an
=C2=A0 =C2=A0OAuth 2.0 authorization grant, this type of tracking can occur=
=C2=A0 =C2=A0whether or not the client identifier is unique by correlating = the
=C2=A0 =C2=A0authenticated resource owner with the requesting client identi= fier.

=C2=A0 =C2=A0Note that clients are forbidden by this specification from cre= ating
=C2=A0 =C2=A0their own client identifier.=C2=A0 If the client were able to = do so, an
=C2=A0 =C2=A0individual client instance could be tracked across multiple co= lluding
=C2=A0 =C2=A0authorization servers, leading to privacy and security issues.=
=C2=A0 =C2=A0Additionally, client identifiers are generally issued uniquely= per
=C2=A0 =C2=A0registration request, even for the same instance of software.= =C2=A0 In
=C2=A0 =C2=A0this way, an application could marginally improve privacy by =C2=A0 =C2=A0registering multiple times and appearing to be completely sepa= rate
=C2=A0 =C2=A0applications.=C2=A0 However, this technique does incur signifi= cant
=C2=A0 =C2=A0usability cost in the form of requiring multiple authorization= s per
=C2=A0 =C2=A0resource owner and is therefore unlikely to be used in practic= e.


Hopefully this is more clear now.

Thanks for the feedback and close review,
=C2=A0=E2=80=94 Justin

> On Feb 24, 2015, at 8:55 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> Yes but it is authenticating the client to the AS as part of the resou= rce owners consent.
>
> Ther eis a one to one mapping of resource owner to client in that case= .
>
> The client ID is no more identifying than the refresh token that maps = to the RO by design.
>
> Yes the grant identifies the RO in some way.=C2=A0 The client_id and s= ecret prevent that from being used in a different client if the bearer toke= n leaks.
>
> Remember the client_id is going to be different at different AS as eac= h will have a separate registration.
> If the client_id was fixed across multiple AS then it would be a corre= lation issue, but that is not the case.
>
> Perhaps I am not understanding the concern?
>
> John B.
>
>> On Feb 18, 2015, at 12:57 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi Justin, Hi John,
>>
>> I believe that provisioning a client with a unique id (which is wh= at a
>> client id/client secret is) allows some form of linkability. While= it
>> may be possible to associate the client to a specific user I could= very
>> well imagine that the correlation between activities from a user a= nd
>> those from the client (particularly when the client is running on = the
>> user's device) is quite possible.
>>
>> Ciao
>> Hannes
>>
>> On 02/18/2015 06:37 PM, Justin Richer wrote:
>>> I=E2=80=99ll incorporate this feedback into another draft, to = be posted by the
>>> end of the week. Thanks everyone!
>>>
>>> =E2=80=94 Justin
>>>
>>>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>>>> <ka= thleen.moriarty.ietf@gmail.com
>>>> <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com
>>>> <mailto:ve7jtb@ve7= jtb.com>> wrote:
>>>>
>>>>=C2=A0 =C2=A0snip
>>>>>=C2=A0 =C2=A0On Feb 18, 2015, at 6:46 AM, Kathleen Mori= arty
>>>>>=C2=A0 =C2=A0<kathleen.moriarty.ietf@gmail.com
>>>>>=C2=A0 =C2=A0<mailto:kathleen.moriarty.ietf@gmail.com>> wrote: >>>>>
>>>>>> The client_id *could* be short lived, but they usu= ally aren't. I don't see any particular logging or tracking concern= s using a dynamic OAuth client above using any other piece of software, eve= r. As such, I don't think it requires special calling out here.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0Help me understand why there should not be= text that shows this
>>>>>=C2=A0 =C2=A0is not an issue or please propose some tex= t.=C2=A0 This is bound to
>>>>>=C2=A0 =C2=A0come up in IESG reviews if not addressed u= p front.
>>>>>
>>>>>
>>>>
>>>>=C2=A0 =C2=A0The client_id is used to communicate to the Au= thorization server
>>>>=C2=A0 =C2=A0to get a code or refresh token.=C2=A0 Those to= kens uniquely identify
>>>>=C2=A0 =C2=A0the user from a privacy perspective.
>>>>=C2=A0 =C2=A0It is the access tokens that are sent to the R= S and those can and
>>>>=C2=A0 =C2=A0should be rotated, but the client)id is not se= nt to the RS in
>>>>=C2=A0 =C2=A0OAuth as part of the spec.
>>>>
>>>>=C2=A0 =C2=A0If you did rotate the client_id then the AS wo= uld track it across
>>>>=C2=A0 =C2=A0rotations, so it wouldn=E2=80=99t really achie= ve anything.
>>>>
>>>>=C2=A0 =C2=A0One thing we don=E2=80=99t do is allow the cli= ent to specify the
>>>>=C2=A0 =C2=A0client_id, that could allow correlation of the= client across
>>>>=C2=A0 =C2=A0multiple AS and that might be a privacy issue,= but we don=E2=80=99t allow it.
>>>>
>>>>
>>>> Thanks, John.=C2=A0 It may be helpful to add in this expla= nation unless
>>>> there is some reason not to?
>>>>
>>>>
>>>>=C2=A0 =C2=A0John B.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Kathleen
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <m= ailto: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
>




--
=

Best regards,
Kathleen
--047d7b3433da3d05310510505c19-- From nobody Mon Mar 2 08:08:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479151A1AB5 for ; Mon, 2 Mar 2015 08:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 uVsGfYZvgA3e for ; Mon, 2 Mar 2015 08:08:03 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 718871A0115 for ; Mon, 2 Mar 2015 08:07:50 -0800 (PST) Received: by labgd6 with SMTP id gd6so31353717lab.7 for ; Mon, 02 Mar 2015 08:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OOirfmx06DBUuEpHz44D5udpGUXBufDp4jgYwgItUn8=; b=zuJaBDdEWM0s1xKty4i+MXTC+0ZIEp7rqpgAJigtT/8ZzI4j4RKa6Eq1oIDXYPC+II K8L/fumbj6ywfV1aktKhQeyHsVJkBAGp75vYfp8YREUzesx+XdUxdfJYF2zdZNRUJiza wVWgoujtinrlI9nOmwHeRHuEK/7IbN8nFrZMvkFWU1/EEPHdmFspf/s/cym7UuM9m8YB SQFg3lilbR3qhtZcoW1pnX5AhcVZgS5UueiGdzPawbCYltWFvlxULBJ8X+14Azufgknp ioTyHSfaPR/sm5qOX8uWjfwFjyzTDcKLFsR7qFouGMceeskz2L9ZwB8hw09bOCnV/EPI ybiA== MIME-Version: 1.0 X-Received: by 10.152.87.134 with SMTP id ay6mr24430883lab.75.1425312468876; Mon, 02 Mar 2015 08:07:48 -0800 (PST) Received: by 10.112.167.101 with HTTP; Mon, 2 Mar 2015 08:07:48 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Mar 2015 11:07:48 -0500 Message-ID: From: Kathleen Moriarty To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c25e5466c11f0510506b88 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-dyn-reg-management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:08:06 -0000 --001a11c25e5466c11f0510506b88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I'd like to see if we can get last call started on this one soon. My questions are not all specific to this draft and I won't hold up this draft for answers that are broader. For this one, if the duplicate TLS text can be addressed, that would be helpful. Then, I'll also need to know more on my questions from the shepherd report in my initial message. I think this should be easy to resolve so we can progress the draft. Thanks, Kathleen On Thu, Feb 26, 2015 at 11:54 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Justin, > > Thanks for the quick response. > > On Thu, Feb 26, 2015 at 11:40 AM, Justin Richer wrote: > >> On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> >> Hello, >> >> I reviewed draft-ietf-oauth-dyn-reg-management, which reads well and I >> just have a few questions and suggestions below that would be good to >> address prior to IETF last call. >> >> Section 1.3 >> Bullet D might be easier to read as a list within the bullet. >> >> >> OK, I=E2=80=99ll try that and see how it renders in the various output f= ormats. >> Lists-within-lists don=E2=80=99t always play nice in my experience, henc= e the >> paragraph format, but we=E2=80=99ll see what it looks like. I agree that= it=E2=80=99s an >> intimidating block of information there. :) >> >> > Thanks for playing with this, it might help. > >> >> Section 2 >> This is something I don't recall offhand and may be in place in another >> draft, so a pointer would be great. Is there an MTI set for one of the >> recommended cipher suites in the TLS & DTLS BCP to ensure interoperabili= ty >> (but also allow for algorithm agility)? If not and there is a reason, >> please explain. >> See section 4: https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ >> This is not the right draft to add this content, but I'd like to know if >> it is covered somewhere or doesn't need to be for some reason. TLS >> requirements should point to that draft (assuming one exists) so there i= s >> only one place to update if needed for any specific requirements to OAut= h. >> >> >> This is a copy of the text found in >> https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#section-5 >> > > Yes, I realized that when I read it, thanks. > >> >> We basically just want to say =E2=80=9Cuse an encrypted channel=E2=80=9D= and point to the >> best guidance there is out there at the time. There shouldn=E2=80=99t be= any >> specific requirements for OAuth. Maybe in the future the IETF could have= a >> standard single reference for transport protection that can be included >> a-la the 2119 definitions? >> > > I brought this up as I read a few drafts for last week's telechat, one wa= s > the BCP for TLS. As a result, it got me digging into a few drafts to see > how it is getting used. Hence, me noticing this possible issue in this > review. > > The TLS protocol itself defines a large number of cipher suites for use > that are registered with IANA (defined per version, but you have to dig > into the referenced specs to see when each was added). > > Then a number of protocols that use TLS define an MTI to ensure interop > between implementations, but typically have an explicit statement to allo= w > for algorithm agility. The recent drafts seem to select one of the > recommended cipher suites from the list int he new TLS BCP. > > Does use of TLS show up in an earlier draft or published OAuth RFC where > this would be appropriate to define? How do implementations ensure inter= op > now? Maybe that will help answer this question. > > >> IANA Considerations: >> The shepherd report says that there are no actions for IANA, so this >> needs to be updated as the draft is the specification required to add tw= o >> new entries to an existing registry, established by the parent document. >> It does require DE review on the mailing list: oauth-ext-review@ietf.org >> If that has been done, then a pointer to the archive would be helpful. >> >> Thank you. >> >> -- >> >> Best regards, >> Kathleen >> >> >> Thanks for the review, >> =E2=80=94 Justin >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --001a11c25e5466c11f0510506b88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'd like to see if we can get l= ast call started on this one soon.

My questions ar= e not all specific to this draft and I won't hold up this draft for ans= wers that are broader. =C2=A0

For this one, if the= duplicate TLS text can be addressed, that would be helpful.

=
Then, I'll also need to know more on my questions from the s= hepherd report in my initial message.=C2=A0 I think this should be easy to = resolve so we can progress the draft.

Thanks,
Kathleen

On Thu, Feb 26, 2015 at 11:54 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hi Justin,

Thanks for = the quick response.

On Thu, Feb 26, 2015 at 11:40 AM, Justin Richer <jr= icher@mit.edu> wrote:
On Feb 26, 2015, at 11:04 AM, Kathleen= Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hello,

I reviewed=C2=A0draft-ietf-oauth-dyn-reg-management, which= reads well and I just have a few questions and suggestions below that woul= d be good to address prior to IETF last call.

Section 1= .3
Bullet D might be easier to read as a list within the bullet.
<= /div>

OK, I=E2=80=99ll try tha= t and see how it renders in the various output formats. Lists-within-lists = don=E2=80=99t always play nice in my experience, hence the paragraph format= , but we=E2=80=99ll see what it looks like. I agree that it=E2=80=99s an in= timidating block of information there. :)


Thanks for playing with this, it m= ight help.=C2=A0

Section 2
This is something I = don't recall offhand and may be in place in another draft, so a pointer= would be great.=C2=A0 Is there an MTI set for one of the recommended ciphe= r suites in the TLS & DTLS BCP to ensure interoperability (but also all= ow for algorithm agility)?=C2=A0 If not and there is a reason, please expla= in.
This is not the right draft to ad= d this content, but I'd like to know if it is covered somewhere or does= n't need to be for some reason.=C2=A0 TLS requirements should point to = that draft (assuming one exists) so there is only one place to update if ne= eded for any specific requirements to OAuth.
=


We basical= ly just want to say =E2=80=9Cuse an encrypted channel=E2=80=9D and point to= the best guidance there is out there at the time. There shouldn=E2=80=99t = be any specific requirements for OAuth. Maybe in the future the IETF could = have a standard single reference for transport protection that can be inclu= ded a-la the 2119 definitions?=C2=A0
=C2= =A0
I brought this up as I read a few drafts for last week= 's telechat, one was the BCP for TLS.=C2=A0 As a result, it got me digg= ing into a few drafts to see how it is getting used.=C2=A0 Hence, me notici= ng this possible issue in this review.

The TLS pro= tocol itself defines a large number of cipher suites for use that are regis= tered with IANA (defined per version, but you have to dig into the referenc= ed specs to see when each was added).

Then a numbe= r of protocols that use TLS define an MTI to ensure interop between impleme= ntations, but typically have an explicit statement to allow for algorithm a= gility.=C2=A0 The recent drafts seem to select one of the recommended ciphe= r suites from the list int he new TLS BCP.=C2=A0

D= oes use of TLS show up in an earlier draft or published OAuth RFC where thi= s would be appropriate to define?=C2=A0 How do implementations ensure inter= op now? Maybe that will help answer this question.
=C2=A0
=
Thank you.
--

Best regards,
Kathl= een

<= div>Thanks for the review,
=C2=A0=E2=80=94 Justin

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



--

=
Best regards,
Kathleen


--

Best regards,
Kath= leen
--001a11c25e5466c11f0510506b88-- From nobody Mon Mar 2 09:09:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161971A1BCA; Mon, 2 Mar 2015 09:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 9bN8aWnhFHz7; Mon, 2 Mar 2015 09:09:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC75E1A1BA7; Mon, 2 Mar 2015 09:09:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150302170947.16118.76859.idtracker@ietfa.amsl.com> Date: Mon, 02 Mar 2015 09:09:47 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Dynamic Client Registration Protocol) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:09:49 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Dynamic Client Registration Protocol' 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 2015-03-16. 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 mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Mar 2 10:22:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324DC1A88AC for ; Mon, 2 Mar 2015 10:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 AQ41mPWrAvxF for ; Mon, 2 Mar 2015 10:21:58 -0800 (PST) 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 4BEAB1A88AD for ; Mon, 2 Mar 2015 10:21:55 -0800 (PST) Received: from [79.253.34.96] (helo=[192.168.71.100]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YSUyX-0007WF-90; Mon, 02 Mar 2015 19:21:53 +0100 Message-ID: <54F4AA3D.4060609@lodderstedt.net> Date: Mon, 02 Mar 2015 19:21:49 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <54F48248.2030706@gmx.net> In-Reply-To: <54F48248.2030706@gmx.net> Content-Type: multipart/alternative; boundary="------------070404010201090407020709" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10: Your feedback needed. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:22:01 -0000 This is a multi-part message in MIME format. --------------070404010201090407020709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes, Am 02.03.2015 um 16:31 schrieb Hannes Tschofenig: > Hi all, > > I am trying to finalize my work on the shepherd write-up of > draft-ietf-oauth-spop. > > Unfortunately, there are still some outstanding issues: > > 1. S256 as a mandatory-to-implement code challenge method > (by the Authorization Server) > > Currently, S256 is MTI but implementations do not use S256 (yet). > Hence, we have very few (maybe not even a single) implementation > that is in conformance with the specification at the moment. > > Does the group see a problem with this choice of MTI > (or lack of conformance)? As already indicated on the list: The original reason to invent spop was to prevent malicous apps, which intercepted the redirect back to the legitimate app and that way impersonated the user (see section 1). In my opinion, "plain" fullfils this goal. I therefore don't see a need (or justification) to make S256 MTI. The security considerations sections says: "If the "plain" method is used, there is a chance that it will be observed by the attacker on the device." Under which circumstances is an attacker supposed to observe the challenge on the device? And if the attacker is able to observe the URLs in an embedded or the system browser, isn't this attacker most likely capable of observing password input in the same browser? In this case, we should rather be concerned regarding the user's password then anything else. kind regards, Torsten. > > 2. Naveen Agarwal has not provided his confirmation that any and > all appropriate IPR disclosures required for full conformance > with the provisions of BCP 78 and BCP 79 have already been filed. > > Without his confirmation I cannot finalize my shepherd write-up. > > 3. Normative language regarding code verifier randomness > > We had a discussion about the language used to describe what > implementations need to provide in terms of randomness of the > code verifier. Here is the discussion thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg14217.html > > Ultimately, the issue boiled down to the following sentence and > the use of 'MUST' vs. 'SHOULD': > > "the code verifier SHOULD have enough entropy to make it > impractical to guess the value" > > It would be good to know whether the group objects using MUST > instead of SHOULD to enhance security. > > Ciao > Hannes > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070404010201090407020709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Hannes,

Am 02.03.2015 um 16:31 schrieb Hannes Tschofenig:
Hi all,

I am trying to finalize my work on the shepherd write-up of
draft-ietf-oauth-spop.

Unfortunately, there are still some outstanding issues:

1. S256 as a mandatory-to-implement code challenge method
(by the Authorization Server)

Currently, S256 is MTI but implementations do not use S256 (yet).
Hence, we have very few (maybe not even a single) implementation
that is in conformance with the specification at the moment.

Does the group see a problem with this choice of MTI
(or lack of conformance)?

As already indicated on the list: The original reason to invent spop was to prevent malicous apps, which intercepted the redirect back to the legitimate app and that way impersonated the user (see section 1). In my opinion, "plain" fullfils this goal. I therefore don't see a need (or justification) to make S256 MTI.

The security considerations sections says:

"If the "plain" method is used,
   there is a chance that it will be observed by the attacker on the
   device."

Under which circumstances is an attacker supposed to observe the challenge on the device? And if the attacker is able to observe the URLs in an embedded or the system browser, isn't this attacker most likely capable of observing password input in the same browser? In this case, we should rather be concerned regarding the user's password then anything else.

kind regards,
Torsten. 


2. Naveen Agarwal has not provided his confirmation that any and
all appropriate IPR disclosures required for full conformance
with the provisions of BCP 78 and BCP 79 have already been filed.

Without his confirmation I cannot finalize my shepherd write-up.

3. Normative language regarding code verifier randomness

We had a discussion about the language used to describe what
implementations need to provide in terms of randomness of the
code verifier. Here is the discussion thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg14217.html

Ultimately, the issue boiled down to the following sentence and
the use of 'MUST' vs. 'SHOULD':

"the code verifier SHOULD have enough entropy to make it
impractical to guess the value"

It would be good to know whether the group objects using MUST
instead of SHOULD to enhance security.

Ciao
Hannes







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

--------------070404010201090407020709-- From nobody Tue Mar 3 01:50:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2921C1A1B21 for ; Tue, 3 Mar 2015 01:50:16 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IILsoCUkGrkm for ; Tue, 3 Mar 2015 01:50:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B7A1A1B18 for ; Tue, 3 Mar 2015 01:50:14 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LjN0F-1XumUg2bT5-00dUl7; Tue, 03 Mar 2015 10:50:09 +0100 Message-ID: <54F583CF.8060109@gmx.net> Date: Tue, 03 Mar 2015 10:50:07 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty , Justin Richer References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kHMJq3t36UPOAKv2ev0s412Of7jnjXcD7" X-Provags-ID: V03:K0:QOULS2nxKHrQGbbW0DHdZdXha3ezFSCGpvPyL0ULy+BMkY7Vd/W Pqoc71vQvYseZvvvpqPVzs1EibxuXJ1gMbPes4z4uywnJbUDnQsFMAw8mpAMP3SkcrFMmEH 1z4cs9jRxEuSZcornOmW+DQyBu799MBN54xwqlQ0ySClA/6ZzeO/3wDH0m2H/MBogB2YHhK Vb3QsHcq+DHZxfTAOnqmg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "" Subject: [OAUTH-WG] IANA Actions and Shepherd Writeup ... Re: AD review of draft-ietf-oauth-dyn-reg-management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 09:50:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kHMJq3t36UPOAKv2ev0s412Of7jnjXcD7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Kathleen, the statement about the IANA actions in the shepherd writeup are indeed incorrect. I updated the writeup. >> IANA Considerations: >> The shepherd report says that there are no actions for IANA, >> so this needs to be updated as the draft is the specification >> required to add two new entries to an existing registry, >> established by the parent document. It does require DE review= >> on the mailing list: oauth-ext-review@ietf.org >> >> If that has been done, then a pointer to the archive would be >> helpful. One question: I was assuming that we would use the review list when requests come from outside the IETF since documents that go through the IETF OAuth working group get detailed review anyway. I am OK with always dropping a mail to the review lists whenever new registry entries are created. Should we do that? Ciao Hannes --kHMJq3t36UPOAKv2ev0s412Of7jnjXcD7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9YPPAAoJEGhJURNOOiAtcm8IAIByvNMGbvugxT88ZM80MwVI hxHRFamhVVzyej/86zYK185E9SsKVzfJaAL3zKVsEyVcXMVCcIO9LVe4JtoDOGcz BwliS7wO+SgE364FoQqGIZS9m3cejsJ8Y+uP8g+nDPWSrUT1DsVVC81ZVYIddPs6 27cpkXeYyRwZIL2jFoWhSMfAkFf4qhptdihZMw/ICQa6lncEvQelKG6QduSO0YN7 INg/G5YHWWyinpHQTOSZs7wXjotvDpdFnvdTArLcfrazsPojfoVJToG2ZZ6akt84 rX6+lnk2d8vrJvUEXdta0b0TVeBWT8IeoJJNx6LxwGbQLr78uQXrM00qwzDqttM= =vY2z -----END PGP SIGNATURE----- --kHMJq3t36UPOAKv2ev0s412Of7jnjXcD7-- From nobody Tue Mar 3 02:56:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B331A0149 for ; Tue, 3 Mar 2015 02:56:30 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ESwIVsLeEmxe for ; Tue, 3 Mar 2015 02:56:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572A21A00DC for ; Tue, 3 Mar 2015 02:56:28 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M2t0Q-1XbKto1m0E-00shCH for ; Tue, 03 Mar 2015 11:56:26 +0100 Message-ID: <54F59359.5020601@gmx.net> Date: Tue, 03 Mar 2015 11:56:25 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w8E7bBFp8fTGvxL9pdP4iKmRR0QMqQcn9" X-Provags-ID: V03:K0:Flz+9t2uz2bZ11DiyUCIqxdqCnqPbWCdA9hDyhvPMNtP7BDskEf XmN+F+mToGypPOKxmifUe57CngGMWRrKCkQ6mnrdZXW1vYR6Na0HiaAATN8bZXFEYGBPHjG +iwrROi+m1jz4nQNqJWVi8EfbCHEd2pKTrLIHtLZcNWZgezzw6BAs5o6kXdiPGpuA+HXVbH uBYqE0CmW45oMiP89DnXQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 10:56:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w8E7bBFp8fTGvxL9pdP4iKmRR0QMqQcn9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, Hi all, in OAuth we provide two ways for a resource server to make an authorization decision. 1) The resource server receives a self-contained token that contains all the necessary information to make a local authorization decision. With the JWT we have created such a standardized information and data model. 2) With an access request from a client the resource server asks the authorization server for "help". The authorization server provides information that help make the authorization decision. This is the token introspection approach. I believe the two approaches need to be aligned with regard to the information and the data model. Since both documents already use JSON as a way to encode information (=3Ddata model) and almost have an identical information model (the data that is being passed around). What needs to be done? * Use the term 'claims' in both documents. * Use the same registry (i.e., the registry established with the JWT). * Register the newly defined claims from the token introspection document in the claims registry. Then, I have a few comments on the new claims that are proposed: Here is the definition of the 'active' claim: active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. This claim is not well-defined. You need to explain what "active" means. It could, for example, mean that the token is not yet expired. Then, there is of course the question why you are not returning the 'exp' claim together with the 'nbf' claim. client_id: What is the resource server going to do with the client_id? What authorization decision could it make? I have a couple of reactions when I read the 'user_id' claim: - I believe the inclusion of a user id field in the response could lead to further confusion regarding OAuth access token usage for authentication. - Since you define it as a human readable identifier I am wondering whether you want to say something about the usage. Here it seems that it might be used for displaying something on a webpage rather than making an authorization decision but I might well be wrong. - I am missing a discussion about the privacy implications of it. While there is a privacy consideration section I am wondering what controls the release of this sensitive information from the authorization server to the resource server. While in some cases the two parties might belong to the same organization but in other cases that may not necessarily be true. - In terms of the information exchanged about the user I am curious about the usefulness of including other information as well, such as the info that is included in an id token (see http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this has nothing to do with the ID token concept and the information carried within it then I would add that remark. Ciao Hannes --w8E7bBFp8fTGvxL9pdP4iKmRR0QMqQcn9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9ZNZAAoJEGhJURNOOiAtIT8H+QFC+dz7Jl4y4jfyErTmyYZt EVgeky7TlO0qmccwKmc910ZJ6rQjzWkS/ayTomH6kGzcy4Ln1aBbyZwIcHGoFmFR bj2YD7/7ot+oQGb5xLaLhzq2/r74jBZdIaLKpaZincgRXnsM0v/qoX7Ki77oHndA f9fwR9eOJEzp0eRM+aBogYT89LBNRjv/2FlpbShyulnW6+0QUVFkA7vziDUGHv20 wPy5k/Arv6NSwfBv1atgILVR2EDLTs2skR6YE0wjvnZ5IwqSiVvdi1sSzM6V1CKv QNDQCu3x01FSw0+iR3ydGEi0oVdpniy8nB6wc/fGcJXoMz2njhm2VsO5bHuCh6k= =wPhu -----END PGP SIGNATURE----- --w8E7bBFp8fTGvxL9pdP4iKmRR0QMqQcn9-- From nobody Tue Mar 3 03:00:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CFF1A1A0B for ; Tue, 3 Mar 2015 03:00:02 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 371fLmvIQTIX for ; Tue, 3 Mar 2015 03:00:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF721A00DC for ; Tue, 3 Mar 2015 03:00:00 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MK3bN-1YRN6p0v8n-001NHb for ; Tue, 03 Mar 2015 11:59:58 +0100 Message-ID: <54F5942C.5010405@gmx.net> Date: Tue, 03 Mar 2015 11:59:56 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VCuB916cdcxgAbqvKWeKSHmEePA0diwIf" X-Provags-ID: V03:K0:FhIxiGGripfHzg3fZdgk1RSPKscYB7dt2BrPmrCxPQt8X+VpKA3 ka7Bk0pprDUlPfK+qE57Cvg0sRU9vsR6XYrw0GS5fXXDfzzGvSL/P224E0HoOz9mA0LbKpM JIRv6EVfl3sm7elZWo21lIAM0wNKRR9gY6oWFbBKgH5gR8xLsl39xIS3LBPYYMSwICggXQT 9ctzimRwMTfz0kKDotO2Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Token Introspection: Misc Review Comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 11:00:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VCuB916cdcxgAbqvKWeKSHmEePA0diwIf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, Hi all, here are some random review comments: FROM: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. " TO: " Since OAuth 2.0 [RFC6749] does not define a protocol between the authorization server and the resource server to retrieve meta-data associated with the access token different approaches to bridge this gap have been developed. " Reason: OAuth 2.0 assumes a relationship between the authorization server and the resource server since otherwise the resource server wouldn't be able to trust the content of the access token. FROM: " The introspection endpoint MUST be protected by TLS of at least version 1.2 RFC 5246 [RFC5246] and MAY support additional transport- layer mechanisms meeting its security requirements. " TO: " The introspection endpoint MUST be protected by TLS of at least version 1.2 RFC 5246 [RFC5246]. " Reason: I have no idea what the "additional transport layer mechanisms ar= e. JWT is listed as an informative reference. I believe it needs to be normative because you depend on the registry being re-used. [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", draft-ietf-oauth-json-web-token (work in progress), July 2014. You write: > The response MAY be cached by the protected resource. It might be worthwhile to say that it may be cached not longer than the lifetime of the token. It would also be good to mention that there is a trade-off between caching and a real-time check in terms of revocation. You write: Specific implementations MAY extend this structure with their own service-specific pieces of information as top-level members of this JSON object. Here I would add that the inclusion of non-standardized tokens need to be based on the agreement between the authorization server and the resource server to avoid confusion and potentially elevation of authorization priviliges. Ciao Hannes --VCuB916cdcxgAbqvKWeKSHmEePA0diwIf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9ZQsAAoJEGhJURNOOiAtnCIIAIZyJgu/TCbQML5eaocf+b3I LbGO90NsuTfwk9/qxKb/4kRhEN+abM1iG2hJ27OjoB77pibOlgAOqEJu6Xaos3kN XcWDY0CaqzcnPPaVwS5ToCwdwJ/tgWgBFtJOI9++5SYX05aY6Fnl3w1M50Zm4XGT McJpavr4kdOs8s7poL84lyla6+AZeXlwGcHWtXTdtQim4mdnzL73Qq9fIinxngY1 0zXKVIo0FFNzn2m7lK0wNmjaX2OIxMfxYxo22MvfI9B2pQER5vniCTGazWbEuoDP 2p6+8YPq0hJ8xCgtV7/NRXb9KClE8Vy0QoU08h0ZVfHY1VjfRyqXzC0215QSG/8= =DbE2 -----END PGP SIGNATURE----- --VCuB916cdcxgAbqvKWeKSHmEePA0diwIf-- From nobody Tue Mar 3 05:00:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734BA1A6F2D for ; Tue, 3 Mar 2015 05:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 dlOdTvXO9Nla for ; Tue, 3 Mar 2015 05:00:15 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 CE4BE1A0056 for ; Tue, 3 Mar 2015 05:00:14 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id i50so1527133qgf.10 for ; Tue, 03 Mar 2015 05:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VlHQUfwh90VLpFRt/7Us3WWYavvAXhRpmb5wCdIGmq8=; b=0s6/7lAJ8kjwYzsbcmYrsw9Jm8CIHAZDglLEi3rHJ9MtluA56c8PGsEA8AEhfy5pPF xyE6pHfoL2fFk5dEGLokpeZmlh3XdhhM4rbdGkMRWgkJj2HbX8uU+oBIHQGRY/Xfoj5P MmbbOSaLL8z6CMWUscVTBbsHPnd+cqwLFy1df3sBfdjMyO/Eb2C2vlwBTJYlryXinY3b j7JniEEv52sDqx2W7GI3436aOXtHXkHQXk1xo78yWEwhINM7y15hPpMY6CZ4akuPeDAP r+Q4tWt3nyo6+L4ZtAHMgBHj9M7M6KHly1pUeOuljg6zc+fKY6Bq+7i/35PvZ4VWk9JK EZaQ== X-Received: by 10.140.165.150 with SMTP id l144mr60037506qhl.39.1425387614039; Tue, 03 Mar 2015 05:00:14 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id y69sm371432qgy.6.2015.03.03.05.00.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Mar 2015 05:00:11 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54F583CF.8060109@gmx.net> Date: Tue, 3 Mar 2015 08:00:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4D1026F4-5C95-4237-9B92-ECD0413B55BD@gmail.com> References: <54F583CF.8060109@gmx.net> To: Hannes Tschofenig Archived-At: Cc: "" Subject: Re: [OAUTH-WG] IANA Actions and Shepherd Writeup ... Re: AD review of draft-ietf-oauth-dyn-reg-management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 13:00:16 -0000 Hi Hannes, Sent from my iPhone > On Mar 3, 2015, at 4:50 AM, Hannes Tschofenig w= rote: >=20 > Hi Kathleen, >=20 > the statement about the IANA actions in the shepherd writeup are indeed > incorrect. I updated the writeup. Thank you! >=20 >>> IANA Considerations: >>> The shepherd report says that there are no actions for IANA, >>> so this needs to be updated as the draft is the specification >>> required to add two new entries to an existing registry, >>> established by the parent document. It does require DE review >>> on the mailing list: oauth-ext-review@ietf.org >>> >>> If that has been done, then a pointer to the archive would be >>> helpful. >=20 > One question: I was assuming that we would use the review list when > requests come from outside the IETF since documents that go through the > IETF OAuth working group get detailed review anyway. >=20 > I am OK with always dropping a mail to the review lists whenever new > registry entries are created. Should we do that? Yes, that's fine and is how I read the IANA considerations. It does say a D= E on that list needs to make a decision, so expert review is required. Thanks, Kathleen >=20 > Ciao > Hannes >=20 From nobody Tue Mar 3 06:20:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84181A86E2 for ; Tue, 3 Mar 2015 06:20:13 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Nthtz0zbfHKo for ; Tue, 3 Mar 2015 06:20:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2921A86DD for ; Tue, 3 Mar 2015 06:20:09 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M4o41-1XYFi41MhZ-00z2fX; Tue, 03 Mar 2015 15:20:05 +0100 Message-ID: <54F5C313.3070507@gmx.net> Date: Tue, 03 Mar 2015 15:20:03 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "oauth@ietf.org" References: <913383AAA69FF945B8F946018B75898A2831D1E6@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2831D1E6@xmb-rcd-x10.cisco.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PsaAnk08ASoubXu4mdIjbV9CuSevTCevE" X-Provags-ID: V03:K0:7+WRDLBZ4ziK6mPkaIBvPtF/5Ufk/Y3tXuvudcG5ZCLiGe4G1BH u8vtB0+NLF9NM9F+6DrPKxzqq+NJAcdr3e9RGkoVVsBeYImB8WmO/Eeq5D755o+cOI7gYLW YOBrpsvdTZzKbRMIP7TOBsPEsB91O67f0JVTNEHSSYU+HSLF13CxsoBXWNLxzzzmpRxdJgY Zj2Rg+ceGX78/OAJKsxBw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-pop-architecture-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 14:20:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PsaAnk08ASoubXu4mdIjbV9CuSevTCevE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Reddy, thanks a lot for your review comments and for failing to notice them. On 08/28/2014 09:05 AM, Tirumaleswar Reddy (tireddy) wrote: > My comments: >=20 > =20 >=20 > 1) Figure 3: Resource server in the response could also generate > Signature/MAC to prove the client that it is in possession of > cryptographic keying material. >=20 Correct. Added. > =20 >=20 > 2) Section 3.2: >=20 > Will new HTTP headers be defined in one of the PoP drafts for the > application layer to carry the TLS channel binding information ? This is up to the solution. >=20 > =20 >=20 > 3)Section 3.3: It is covering various attack scenarios except active, > man-in-middle attack. >=20 Section 3 discusses use cases. Section 3.3 describes a scenario where TLS is not used and the need for an alternative security solution (other than bearer arises). I think an active man-in-the-middle use case would not be a good suggestion ;-) > =20 >=20 > 4)Why only discuss TLS and not DTLS ? The members of the design team where this work came from focused on the web. I agree that this work is equally applicable to the non-Web environment (as the recent work in the ACE group had shown). I would, however, leave it to the ACE working group to explore the use of OAuth for IoT (with DTLS, CoAP, etc.), if there is enough interest. >=20 > =20 >=20 > 5)Section 3.4: Enterprise networks, ISP etc. may also deploy HTTP(S) pr= oxy. >=20 Sentence added. > =20 >=20 > 6)Please explain scenarios in which using asymmetric cryptography is > better suited for PoP than using symmetric cryptography. While symmetric cryptography provides better performance properties the use of asymmetric cryptography allows the client to keep the private key locally and never expose it to any other party. I would see this as a strong security benefit that will more and more important in the future as we see backend database systems hacked over and over again. >=20 > =20 >=20 > 7)I don=92t see any discussion on HMAC algorithm negotiation b/w the > client and resource server. >=20 > It may help to define mandatory to implement and default algorithms.= >=20 >=20 I added a note about it. >=20 > 8)Protocols like Dynamic Symmetric Key Provisioning Protocol (DSKPP) > (RFC6063) could be considered for long-term secret b/w the AS and RS. >=20 > =20 DSKPP would indeed be a viable solution for distributing symmetric keys. >=20 > 9)Nit> Figure 4: Add arrows for (V) and (IV) >=20 Thanks. Fixed. > =20 >=20 > 10) AS-to-RS Relationship Anonymity: >=20 > =20 >=20 > This MAC Token security does not provide AS-to-RS relationship >=20 > anonymity since the client has to inform the resource server abou= t >=20 > the resource server it wants to talk to. >=20 >=20 >=20 > Nit> I think you meant =93inform the authorization server about the > resource server it wants to talk to=94 >=20 I changed this paragraph. Thanks again for reading through the document so carefully. Ciao Hannes > =20 >=20 > Cheers, >=20 > -Tiru >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --PsaAnk08ASoubXu4mdIjbV9CuSevTCevE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9cMTAAoJEGhJURNOOiAtGY8H/jwxEPVDUSeNr1bn5Y9HOkaR APoefdMMAWzQLvMWm/EqrF83qvDV5WfoTqTzoJJjAuk13gVYmMJKE8XVUQDSXLUb o5fPlJPgM+vI51F6WA+14xFRQILuZJtaoEUlyphLh8CxpNCwIHwV5mOIZo0yNDkB yqb2RwNfQ34Fz4LbNzyte6ECeF261U0sR/1PmqkipCcCPO2gTkTASr0meFmNCekw cHBim6eNDfXeX7R3/23I+zNmDAHVgcPOMLyjyQ54aK0HpRk33MMMVl+gGHmmHtnF BjGlsDZJGq3fJsxTAgc2M2F7ilvyPxRiAc5J6aUCX0Aok0HIlXVnb4UkV8tbUWc= =7+qY -----END PGP SIGNATURE----- --PsaAnk08ASoubXu4mdIjbV9CuSevTCevE-- From nobody Tue Mar 3 06:21:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36C81A86F1; Tue, 3 Mar 2015 06:21:04 -0800 (PST) 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] autolearn=ham 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 LPPA1_PhOiTW; Tue, 3 Mar 2015 06:21:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6971A86E0; Tue, 3 Mar 2015 06:21:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150303142103.12620.65526.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 06:21:03 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 14:21:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Authors : Phil Hunt Justin Richer William Mills Prateek Mishra Hannes Tschofenig Filename : draft-ietf-oauth-pop-architecture-01.txt Pages : 23 Date : 2015-03-03 Abstract: The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must to be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 3 09:28:05 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20B1AC3ED for ; Tue, 3 Mar 2015 09:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 DI7oiiCLCOTT for ; Tue, 3 Mar 2015 09:27:52 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003: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 F1DF41ABC75 for ; Tue, 3 Mar 2015 09:27:51 -0800 (PST) Received: by oiav63 with SMTP id v63so783456oia.8 for ; Tue, 03 Mar 2015 09:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=RyqMSAPLgqfB10wvnyCHeWijDB2aEGIwpWHlyhEh/Dc=; b=Im/Rk2/MMGTJk3Kk7yxtBqlf04R7GGh72B/tsAqcxbT0Rdwf4Z9X4X4wUgQwKqxecL OEyEDdsXE3/nL++x/7UUqTt4u8TYtNYhG2bRmDWnliq3SqKsNTKC0vUHM56VYukziLkx IuuWluAKYuQEg7BZCdUnh2eleS+umSTAtw4qs1XYv+Osg0hJwaCtaZ8optGUcXB0nSb5 vAafKajoTeMcXlnrfadj8YPilf56zx9QwINiYC+wjgcbipfSEcakdNHNrQwDlDePMp5o Q/WvDRcqeC/XdjkNG+WRhtNUn5UYhPkvFIJA0j3u9CmEcvKJ9/iDBr8zprOu+EAiJxq2 Om3Q== X-Received: by 10.202.188.66 with SMTP id m63mr23337oif.14.1425403671291; Tue, 03 Mar 2015 09:27:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.97.102 with HTTP; Tue, 3 Mar 2015 09:27:31 -0800 (PST) From: Josh Mandel Date: Tue, 3 Mar 2015 09:27:31 -0800 Message-ID: To: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary=001a113dd6887d2ed6051065a725 Archived-At: Cc: Matt Randall , Dixie Baker Subject: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 17:27:58 -0000 --001a113dd6887d2ed6051065a725 Content-Type: text/plain; charset=ISO-8859-1 Hi All, In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process." In other words, this mitigation would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like: https://auth-server/authorize? response_type=code& client_id=123& state=456& scope=read-all& redirect_uri=https://app-server/after-auth& *resource_server_that_told_me_to_authorize_here=https://attacker.com * (And if the authorization server saw a value it didn't like in the final parameter, it would reject the request.) This is obviously not appropriate in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.) If so, what should it be called? The name I used in the example above is a bit verbose :-) Best, Josh --001a113dd6887d2ed6051065a725 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

In section 4.6.4 (&q= uot;Threat: Access Token Phishing by Counterfeit Resource Server"), RF= C6819 describes a threat where a counterfeit resource server tricks a clien= t into obtaining and sharing an access token from a legitimate authorizatio= n server. One of the proposed mitigations involves: "telling the autho= rization server about the resource server endpoint URL in the authorization= process."

In other words, this mitigation wo= uld ask the client to pass an additional parameter when redirecting to the = Authorization server's "authorize" URL, effectively something= like:

response_type=3Dcode&<= /div>
client_id=3D123&
state=3D456&
scope=3Dread-all&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it didn't like in the f= inal parameter, it would reject the request.)

This= is obviously not appropriate in every authorization scenario, but it is us= eful anytime there's a discovery process by which apps learn about auth= orization servers from resource servers. Since it's something of a comm= on need, I wanted to see if there was any common practice in how to name th= is parameter, or whether it's worth registering a standard extension at= =A0http://www.iana.org/assignments/oauth-parameters/oauth-paramete= rs.xhtml . (I don't see one there now -- possibly I'm just miss= ing it.)

If so, what should it be called? The name= I used in the example above is a bit verbose :-)

= Best,

=A0 Josh
--001a113dd6887d2ed6051065a725-- From nobody Wed Mar 4 06:41:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6B91A1BCB for ; Wed, 4 Mar 2015 06:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 1Wjp9BUB7fHt for ; Wed, 4 Mar 2015 06:41:00 -0800 (PST) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5D11A1B8E for ; Wed, 4 Mar 2015 06:41:00 -0800 (PST) Received: from [192.168.131.141] ([80.92.121.102]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lcjgd-1XjQKL0BMd-00k4Am for ; Wed, 04 Mar 2015 15:40:58 +0100 Message-ID: <54F71978.5090804@gmx.net> Date: Wed, 04 Mar 2015 15:40:56 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GjmJmP7dUBacekC17HwmnFjxbQWOehLDG" X-Provags-ID: V03:K0:7JIFqMLQF84gk+ISBwhGnTrkheWVONNudYPjIfthocSG2bZk3UI 7V1Jpc+TGmedfjoKafDifWY6oKJ4nAdQqnA7H++0lTL/u84kmDQBisaDZo6SpwSBDGFwPTV SkEHMtTKplrWHfaPHljLk3+dkwLVdB+zq6NiiOjqKGF4BLNm9TCUpU+JvMmamekR+1PY80k eb5fVfE+5ACJHCbVxL0zw== X-UI-Out-Filterresults: junk:10; Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 14:41:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GjmJmP7dUBacekC17HwmnFjxbQWOehLDG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, as the deadline is approaching I would like to close the open issues of the document. There are two open issues listed in the document and I propose ways to resolve them below Open Issue #1: "In some conversations, we have said that it is the issuer of the JWT that possesses the key, and in some conversations, we have said that it is the presenter of the JWT that possesses the key. Which description should we use? " There are the following parties in the entire picture (as the PoP architecture document illustrates quite nicely): * Issuer: Party that creates the JWT and binds a key to the token. The key may be a symmetric key or a public key. To bind the key to the JWT the issuer needs to compute a digital signature or a keyed message digest over the JWT. * Presenter: Party that demonstrates possession of a private key (for asymmetric key cryptography) and secret key (for symmetric key cryptography) to a recipient. * Recipient: Party that receives the JWT together with the proof of possession of the key (typically in form of a digital signature or a keyed message digest). Mapping this terminology to the OAuth context would look as follows: - Issuer: OAuth Authorization Server - Presenter: OAuth Client - Recipient: OAuth Resource Server Adding the above-mentioned terminology to the terminology section (and deleting the currently listed presenter) would resolve the issue IMHO. Open Issue#2: Mike added an editorial note to the introduction saying: " [[ Editorial Note: This paragraph needs to be updated to provide more context and possibly also to describe the use of asymmetric keys instead. It's not clear that the symmetric case is as useful or valuable, and it is certainly more complicated.]] " The design team work clearly indicated that both symmetric and asymmetric cryptography has to be supported. The JWT mechanism actually supports both and hence we should also describe both. What can, however, be done is to also describe the asymmetric key case and here is my text proposal for the introduction. ---- 1. Introduction This specification defines how to bind a key to a JSON Web Token (JWT) [JWT]. Three parties act in such a scenario: * Issuer: Party that creates the JWT and binds a key to the token. The key may be a symmetric key or a public key. To bind the key to the JWT the issuer needs to compute a digital signature or a keyed message digest over the JWT. * Presenter: Party that demonstrates possession of a private key (for asymmetric key cryptography) and secret key (for symmetric key cryptography) to a recipient. This property is also sometimes described as the presenter being a holder-of-key. * Recipient: Party that receives the JWT together with the proof of possession of the key (typically in form of a digital signature or a keyed message digest). [I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession semantics for JSON Web Tokens (JWTs) for the use with OAuth. Envision the following two use cases. The first use case describes the use of a symmetric key and the second use case focuses on asymmetric cryptography. An OAuth 2.0 authorization server generates a JWT and places an encrypted symmetric key inside the newly introduced confirmation claim. This symmetric key is encrypted with a key known only to the authorization server and the recipient. The entire JWT is then integrity protected. The JWT is then sent to the presenter. Since the presenter is unable to obtain the encrypted symmetric key from the JWT itself, the authorization server conveys that symmetric key separately to the presenter. Now, the presenter is in possession of the symmetric key as well as the JWT (which includes the confirmation claim member). When the presenter needs to present the JWT to the recipient, it also needs to demonstrate possession of the symmetric key; the presenter, for example, uses the symmetric key in a challenge/response protocol with the recipient. The recipient is able to verify that it is interacting with the genuine presenter by decrypting the JWK contained inside the confirmation claim of the JWT. By doing this the recipient obtains the symmetric key, which it then uses to verify cryptographically protected messages exchanged with the presenter. This symmetric key mechanism described above is conceptually similar to the use of Kerberos tickets. In the second case consider a presenter that generates a public / private key pair. It then sends the public key to an OAuth 2.0 authorization server, which creates a JWT and places an public key (or a fingerprint of it) inside the newly introduced confirmation claim. The entire JWT is then integrity protected using a digital signature to protect it against modifications. The JWT is then sent to the presenter. When the presenter needs to present the JWT to the recipient, it also needs to demonstrate possession of the private key. The presenter, for example, uses the private key in TLS exchange with the recipient. The recipient is able to verify that it is interacting with the genuine presenter by extracting the public key from the confirmation claim of the JWT (after verifying the digital signature of the JWT) and utilizing it with the private key in the TLS exchange. The asymmetric key mechanism described above is conceptually similar to a certificate. In both cases the JWT may contain various claims that are included based on the policy of the authorization server. ---- Due to the IETF draft submission deadline we would appreciate a response by next Sunday. Ciao Hannes --GjmJmP7dUBacekC17HwmnFjxbQWOehLDG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9xl4AAoJEGhJURNOOiAtIikH/js9hMG97gt2SQ5ZwnCWQ0fd TJmEFK2clpzLPRVH24WOOXuZ6Lt09ZQGUkzBK1h0L0Lmjy+IFBmyxdxiy7nKZCLB 65eEnptvIA12zmMaigHQtO0VHS6kPznDRA7D5wlt9YbxUbuY8gZdsRkCDHE/UpxV aGT5XX4g1TAa4A6AWmmMVpKTEIqlsA3KcgCEmLFKgpzyUQF4gkWcAhxD5QwqDTGF c4FtJdRaBk9CsMq+tLWPG/HKPAeTTmwqV0PW2LjSb+4cjTTlbzcNJt2OHShv5kDv ptokISHDNlFL0Qq6Sbr3/ak15e+OVWyno3GZNjllIFf3529iNIxrsNyGyZgGwKE= =0cEC -----END PGP SIGNATURE----- --GjmJmP7dUBacekC17HwmnFjxbQWOehLDG-- From nobody Wed Mar 4 13:31:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F64E1A1B98 for ; Wed, 4 Mar 2015 13:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zU-SNFlQLA6J for ; Wed, 4 Mar 2015 13:31:47 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DEA1A1ABF for ; Wed, 4 Mar 2015 13:31:46 -0800 (PST) X-AuditID: 12074424-f79356d000004839-50-54f779c13164 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 38.2D.18489.1C977F45; Wed, 4 Mar 2015 16:31:45 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t24LViXO001431; Wed, 4 Mar 2015 16:31:44 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t24LVgZc009708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Mar 2015 16:31:44 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_023B9FF0-266C-496D-9661-971C0B6B8EF2"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Justin Richer In-Reply-To: <54F5942C.5010405@gmx.net> Date: Wed, 4 Mar 2015 16:31:49 -0500 Message-Id: References: <54F5942C.5010405@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsUixG6nonuw8nuIwcRDfBZLd95jtTj59hWb A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJWx7eRLloLZihUz7j9jamD8KdXFyMkhIWAi 0TDvFxuELSZx4d56IJuLQ0hgMZPEns5rzBDOBkaJqdPvsUA4D5gkDq9axQrSIizgKHGk7S9Y O6+AgcTcU1+YQIqYBSYxSrQe28UCMVdK4sHtNYwgNpuAqsT0NS1MIDangLrEgoa/7F2MHBws AioSK/utQExmoHD7SReIkVYSMw5MAKsWElCTuHq7B2ytiIChxPWZ01lByiUE5CV6NqVPYBSc heSIWciOAEkwC2hLLFv4mhnC1pTY370cKi4vsf3tHKi4pcTimTeg4rYSt/oWMEHYdhKPpi1i XcDIsYpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyM4clxUdjA2H1I6xCjAwajE w3sg9luIEGtiWXFl7iFGSQ4mJVFev4rvIUJ8SfkplRmJxRnxRaU5qcWHGFWAdj3asPoCoxRL Xn5eqpIIr50LUB1vSmJlVWpRPkyZNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQleC5AF gkWp6akVaZk5JQhpJg7OQ4wSHDxAw7NAaniLCxJzizPTIfKnGBWlxHkNQRICIImM0jy4XljC e8UoDvSWMO8SkCoeYLKE634FNJgJaPAtxS8gg0sSEVJSDYzBh2/MbUyvv/L7YtR59f9xRXIK zKzWuepF0x9vl3kSdUfju/n0uz/yZ+zPZV1q2aXAp/ddyWzhpqS0JI9kax9FJ5WSnlvFjxON xSe3HtSfdeTAtT65WfNkrqup9FbWfl2fcfuu/ifpRdFfyw2YBFeqBYSzFEwVOHFjcaLYwvrv ri8+6m+ftVuJpTgj0VCLuag4EQBaB0X2UwMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Introspection: Misc Review Comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 21:31:49 -0000 --Apple-Mail=_023B9FF0-266C-496D-9661-971C0B6B8EF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 3, 2015, at 5:59 AM, Hannes Tschofenig = wrote: >=20 > Hi Justin, Hi all, >=20 > here are some random review comments: >=20 > FROM: >=20 > " Since > OAuth 2.0 [RFC6749] defines no direct relationship between the > authorization server and the protected resource, only that they must > have an agreement on the tokens themselves, there have been many > different approaches to bridging this gap. > " >=20 > TO: > " Since OAuth 2.0 [RFC6749] does not define a protocol between the > authorization server and the resource server to retrieve > meta-data associated with the access token different approaches to > bridge this gap have been developed. > " >=20 > Reason: OAuth 2.0 assumes a relationship between the authorization > server and the resource server since otherwise the resource > server wouldn't be able to trust the content of the access token. >=20 Thanks, this is more accurate. > FROM: >=20 > " > The introspection endpoint MUST be protected by TLS of at least > version 1.2 RFC 5246 [RFC5246] and MAY support additional transport- > layer mechanisms meeting its security requirements. > " >=20 > TO: >=20 >=20 > " > The introspection endpoint MUST be protected by TLS of at least > version 1.2 RFC 5246 [RFC5246]. > " >=20 > Reason: I have no idea what the "additional transport layer mechanisms = are. >=20 >=20 This has been common verbiage, but after Kathleen=E2=80=99s comments on = Dyn-Reg we probably want to adopt that block of text instead anyway, = which includes the TLS BCP reference. > JWT is listed as an informative reference. I believe it needs to be > normative because you depend on the registry being re-used. >=20 > [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token > (JWT)", draft-ietf-oauth-json-web-token (work in > progress), July 2014. >=20 >=20 Good point, previous drafts didn=E2=80=99t reference the registry so = this needs to be upgraded to normative. > You write: >> The response MAY be cached by the protected resource. >=20 > It might be worthwhile to say that it may be cached not longer than = the > lifetime of the token. It would also be good to mention that there is = a > trade-off between caching and a real-time check in terms of = revocation. It=E2=80=99s always a tradeoff and we can give some guidance, but = we=E2=80=99re not going to solve cache consistency here. Can you suggest = text for how to strike this balance? >=20 > You write: >=20 > Specific implementations MAY extend this structure with their own > service-specific pieces of information as top-level members of this > JSON object. >=20 > Here I would add that the inclusion of non-standardized tokens need to > be based on the agreement between the authorization server and the > resource server to avoid confusion and potentially elevation of > authorization priviliges. That seems like reasonable guidance, can you suggest text? Thanks, =E2=80=94 Justin >=20 > Ciao > Hannes >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_023B9FF0-266C-496D-9661-971C0B6B8EF2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJU93nFAAoJEDPAngkbd+w9TT4H/jaqzuw9o5yNc0rxwgyBfNB3 lgoXI5vufkZHZFy8geFSDJXmCK3xRPylV9DBzugDHWwl7Xk1E+4Tlw0IAI+rijFy y1wEsoWcrqrmd3zwDr10eIADHD0WWx8SjUzA/r52IiooM/avv6ppe4gONIuVVh3u ktet49/7TO46V6SBL+aauBDfqIyKJCPglvTBrvEFb0en5VRlvRDqI7o+zhRKsTXq CV2mn/bgCP0KU2AlBck3PJwCNUqRWR8xDW6DlHbT+F6uum9nIh7ArkX8xFr2iOPx nMYzFcRvAelG/F9IsimzmkRPUcQDdr/HCUdd0kZOes+dlG7rDyHbJhh5lF4jEhI= =2fgW -----END PGP SIGNATURE----- --Apple-Mail=_023B9FF0-266C-496D-9661-971C0B6B8EF2-- From nobody Wed Mar 4 13:46:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDB91A893B for ; Wed, 4 Mar 2015 13:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bqTgHAFWYOiB for ; Wed, 4 Mar 2015 13:45:55 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6485A1A8963 for ; Wed, 4 Mar 2015 13:45:55 -0800 (PST) X-AuditID: 1209190f-f79546d000007593-1e-54f77d11ab14 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 44.FD.30099.11D77F45; Wed, 4 Mar 2015 16:45:53 -0500 (EST) 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 t24LjrrR001551; Wed, 4 Mar 2015 16:45:53 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t24Ljp25019308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Mar 2015 16:45:52 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_064A87E6-A1C0-46F4-A636-8925D245F017" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Justin Richer In-Reply-To: <54F59359.5020601@gmx.net> Date: Wed, 4 Mar 2015 16:45:58 -0500 Message-Id: <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> References: <54F59359.5020601@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT1xWs/R5isHS2qcXSnfdYLU6+fcXm wOSxeNN+No8lS34yBTBFcdmkpOZklqUW6dslcGU8vLaCrWBHN2PFvyNtLA2MnaVdjJwcEgIm Eg0TdjND2GISF+6tZ+ti5OIQEljMJNH2dyqUs4FR4vn8c+wQzgMmialzl7ODtDALJEgsfn8Y zOYVMJCYe+oLE4gtLBAgsWLbSVYQm01AVWL+yltgcU4BdYmj83+A1bMIqEi8PXwOKM4BNEdd ov2kC4jJK2Alsed2KkiFkICaxLRTrxlBbBEBQ4nrM6ezgpRICMhL9GxKn8AoMAvJDbOQ3AAR 15ZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zro5WaW 6KWmlG5iBIU7pyT/DsZvB5UOMQpwMCrx8GZEfwsRYk0sK67MPcQoycGkJMrrV/E9RIgvKT+l MiOxOCO+qDQntfgQowQHs5IIr50LUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFq EUxWhoNDSYL3ajVQo2BRanpqRVpmTglCmomDE2Q4D9DwDyA1vMUFibnFmekQ+VOMilLivNtB EgIgiYzSPLheWDp6xSgO9Iowr2INUBUPMJXBdb8CGswENPiW4heQwSWJCCmpBkaxm1r/Fjr9 ulO+9DeX++d2Lefrxzcf+fFVZWPUqnhHlwWeU30uX2S6YZO3kbs2tG71FgfZeVcT+36vd5Tj /N9Z1f+sP/aHIf/O/9sPn7wknttzRG+RhZirzo6tchK29Z6LnwVz/+sKCOialS90tsimgrEh UzmNNSdkndvK71debTGzaq9aW6DEUpyRaKjFXFScCACOVpbCIgMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 21:45:58 -0000 --Apple-Mail=_064A87E6-A1C0-46F4-A636-8925D245F017 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Hannes, thanks for the feedback. Responses inline. > On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig = > wrote: >=20 > Hi Justin, Hi all, >=20 > in OAuth we provide two ways for a resource server to make an > authorization decision. >=20 > 1) The resource server receives a self-contained token that contains = all > the necessary information to make a local authorization decision. With > the JWT we have created such a standardized information and data = model. >=20 > 2) With an access request from a client the resource server asks the > authorization server for "help". The authorization server provides > information that help make the authorization decision. This is the = token > introspection approach. >=20 > I believe the two approaches need to be aligned with regard to the > information and the data model. Since both documents already use JSON = as > a way to encode information (=3Ddata model) and almost have an = identical > information model (the data that is being passed around). >=20 > What needs to be done? >=20 > * Use the term 'claims' in both documents. > * Use the same registry (i.e., the registry established with the JWT). > * Register the newly defined claims from the token introspection > document in the claims registry. >=20 We=E2=80=99ve already done this in the latest draft. Or at least, = that=E2=80=99s the intent of the current text =E2=80=94 the registry is = referenced and the new claims are registered. Can you specifically point = to places where this needs to be improved upon? > Then, I have a few comments on the new claims that are proposed: >=20 > Here is the definition of the 'active' claim: >=20 > active > REQUIRED. Boolean indicator of whether or not the presented = token > is currently active. The authorization server determines whether > and when a given token is in an active state. >=20 > This claim is not well-defined. You need to explain what "active" = means. > It could, for example, mean that the token is not yet expired. Then, > there is of course the question why you are not returning the 'exp' > claim together with the 'nbf' claim. The definition of =E2=80=9Cactive=E2=80=9D is really up to the = authorization server, and I=E2=80=99ve yet to hear from an actual = implementor who=E2=80=99s confused by this definition. When you=E2=80=99re= the one issuing the tokens, you know what an =E2=80=9Cactive=E2=80=9D = token means to you. Still, perhaps we can be even more explicit, such = as: active REQUIRED. Boolean indicator of whether or not the presented token is = currently active. The specifics of a token=E2=80=99s active state will = vary depending on the implementation of the authorization server, but = generally this will indicate that a given token has been issued by this = authorization server, has not been revoked by the resource owner, and is = within its given time window of validity (e.g. not expired).=20 Also, this is one of the places where the overlap between JWT and = introspection claims don=E2=80=99t make sense. It doesn=E2=80=99t make = any sense for a JWT to carry an =E2=80=9Cactive=E2=80=9D claim at all. = Why would you have a JWT claim to be anything but active? We should = register it with the JWT registry to avoid name collisions, but = there=E2=80=99s nothing in the JWT registry that says =E2=80=9Cdon=E2=80=99= t use this inside of a JWT=E2=80=9D. Do you have any advice on how to = address this? >=20 > client_id: What is the resource server going to do with the client_id? > What authorization decision could it make? Whatever it wants to. If an RS can figure out something from the = client_id, why not let it? The client_id is a piece of information about = the context of the issuance of the token, and a common enough OAuth = value for decision making.=20 > I have a couple of reactions when I read the 'user_id' claim: > - I believe the inclusion of a user id field in the response could > lead to further confusion regarding OAuth access token usage for > authentication. This isn=E2=80=99t any different from having a userinfo-endpoint = equivalent (like social graph or twitter API) and it=E2=80=99s got the = same trouble.=20 >=20 > - Since you define it as a human readable identifier I am wondering > whether you want to say something about the usage. Here it seems that = it > might be used for displaying something on a webpage rather than making > an authorization decision but I might well be wrong. We added in =E2=80=9Cuser_id=E2=80=9D to our implementation due to = developer demand =E2=80=94 they wanted a username associated with the = return value, but to leave the =E2=80=9Csub=E2=80=9D value the same as = that defined by OpenID Connect. Note that this is in an environment = where the username is a known quantity, and they=E2=80=99re not trying = to do cross-domain authentication. They just want to know whose token = this was so they can figure out whose data to return. It=E2=80=99s not = used for display, but I tried to make the definition in contrast to the = machine-facing =E2=80=9Csub=E2=80=9D value. >=20 > - I am missing a discussion about the privacy implications of it. > While there is a privacy consideration section I am wondering what > controls the release of this sensitive information from the > authorization server to the resource server. While in some cases the = two > parties might belong to the same organization but in other cases that > may not necessarily be true. You=E2=80=99re correct, this is currently missing and I=E2=80=99ll add = that in. >=20 > - In terms of the information exchanged about the user I am curious > about the usefulness of including other information as well, such as = the > info that is included in an id token (see > http://openid.net/specs/openid-connect-core-1_0.html#IDToken = ). If this > has nothing to do with the ID token concept and the information = carried > within it then I would add that remark. You could introspect an ID token if you wanted to, but it=E2=80=99s = usually easier to just parse it yourself because it=E2=80=99s = self-contained. The ID Token also extends JWT, so there=E2=80=99s = nothing stopping you from returning those claims as well. However, note = that the audience of the ID token is the OAuth *client* whereas the = targeted user of the introspection endpoint is the *protected resource*. = The PR isn=E2=80=99t going to see the ID Token most of the time, and the = client=E2=80=99s not going to need to (or be able to) introspect its = tokens most of the time, so in practice there=E2=80=99s not really any = overlap. =E2=80=94 Justin >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_064A87E6-A1C0-46F4-A636-8925D245F017 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Hannes, thanks for the feedback. Responses inline.

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig = <hannes.tschofenig@gmx.net> wrote:

Hi Justin, Hi = all,

in OAuth we provide two ways for a = resource server to make an
authorization decision.

1) The resource server receives a = self-contained token that contains all
the necessary = information to make a local authorization decision. With
the= JWT we have created such a standardized information and data model.

2) With an access request from a client the = resource server asks the
authorization server for "help". = The authorization server provides
information that help = make the authorization decision. This is the token
introspection approach.

I = believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already = use JSON as
a way to encode information (=3Ddata model) = and almost have an identical
information model (the data = that is being passed around).

What needs to = be done?

* Use the term 'claims' in both = documents.
* Use the same registry (i.e., the registry = established with the JWT).
* Register the newly defined = claims from the token introspection
document in the claims = registry.


We=E2=80=99ve already = done this in the latest draft. Or at least, that=E2=80=99s the intent of = the current text =E2=80=94 the registry is referenced and the new claims = are registered. Can you specifically point to places where this needs to = be improved upon?

Then, I have a few comments on the new claims = that are proposed:

Here is the definition = of the 'active' claim:

=   active
=      REQUIRED.  Boolean indicator of = whether or not the presented token
=      is currently active.  The = authorization server determines whether
=      and when a given token is in an active = state.

This claim is not well-defined. You = need to explain what "active" means.
It could, for = example, mean that the token is not yet expired. Then,
there= is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

The definition of =E2=80=9Cactive=E2=80=9D is really up to = the authorization server, and I=E2=80=99ve yet to hear from an actual = implementor who=E2=80=99s confused by this definition. When you=E2=80=99re= the one issuing the tokens, you know what an =E2=80=9Cactive=E2=80=9D = token means to you. Still, perhaps we can be even more explicit, such = as:


active
  REQUIRED. Boolean indicator of whether or not the = presented token is currently active. The specifics of a token=E2=80=99s = active state will vary depending on the implementation of the = authorization server, but generally this will indicate that a given = token has been issued by this authorization server, has not been revoked = by the resource owner, and is within its given time window of validity = (e.g. not expired). 

Also, = this is one of the places where the overlap between JWT and = introspection claims don=E2=80=99t make sense. It doesn=E2=80=99t make = any sense for a JWT to carry an =E2=80=9Cactive=E2=80=9D claim at all. = Why would you have a JWT claim to be anything but active? We should = register it with the JWT registry to avoid name collisions, but = there=E2=80=99s nothing in the JWT registry that says =E2=80=9Cdon=E2=80=99= t use this inside of a JWT=E2=80=9D. Do you have any advice on how to = address this?


client_id: What is the = resource server going to do with the client_id?
What = authorization decision could it make?

Whatever it wants to. If an RS can figure out something from = the client_id, why not let it? The client_id is a piece of information = about the context of the issuance of the token, and a common enough = OAuth value for decision making. 

I have a couple of reactions = when I read the 'user_id' claim:
 - I believe the = inclusion of a user id field in the response could
lead to = further confusion regarding OAuth access token usage for
authentication.

This isn=E2=80=99t any = different from having a userinfo-endpoint equivalent (like social graph = or twitter API) and it=E2=80=99s got the same trouble. 


 - Since you define it as a human readable identifier I = am wondering
whether you want to say something about the = usage. Here it seems that it
might be used for displaying = something on a webpage rather than making
an authorization = decision but I might well be wrong.

We added in = =E2=80=9Cuser_id=E2=80=9D to our implementation due to developer demand = =E2=80=94 they wanted a username associated with the return value, but = to leave the =E2=80=9Csub=E2=80=9D value the same as that defined by = OpenID Connect. Note that this is in an environment where the username = is a known quantity, and they=E2=80=99re not trying to do cross-domain = authentication. They just want to know whose token this was so they can = figure out whose data to return. It=E2=80=99s not used for display, but = I tried to make the definition in contrast to the machine-facing = =E2=80=9Csub=E2=80=9D value.


 - I am missing a = discussion about the privacy implications of it.
While = there is a privacy consideration section I am wondering what
controls the release of this sensitive information from = the
authorization server to the resource server. While in = some cases the two
parties might belong to the same = organization but in other cases that
may not necessarily = be true.

You=E2=80=99re correct, this is = currently missing and I=E2=80=99ll add that in.


 - In terms of the information exchanged about the user = I am curious
about the usefulness of including other = information as well, such as the
info that is included in = an id token (see
http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this
has nothing to do with the ID token concept = and the information carried
within it then I would add = that remark.


You = could introspect an ID token if you wanted to, but it=E2=80=99s usually = easier to just parse it yourself because it=E2=80=99s self-contained. = The ID Token also extends JWT, so there=E2=80=99s nothing stopping you = from returning those claims as well. However, note that the audience of = the ID token is the OAuth *client* whereas the targeted user of the = introspection endpoint is the *protected resource*. The PR isn=E2=80=99t = going to see the ID Token most of the time, and the client=E2=80=99s not = going to need to (or be able to) introspect its tokens most of the time, = so in practice there=E2=80=99s not really any overlap.

 =E2=80=94 = Justin


Ciao
Hannes

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

= --Apple-Mail=_064A87E6-A1C0-46F4-A636-8925D245F017-- From nobody Wed Mar 4 14:01:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DAA1A893E for ; Wed, 4 Mar 2015 14:01:19 -0800 (PST) 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 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 pv_d8I6fEmUh for ; Wed, 4 Mar 2015 14:01:17 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (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 1F1351A8978 for ; Wed, 4 Mar 2015 14:01:17 -0800 (PST) Received: by wesx3 with SMTP id x3so2621221wes.4 for ; Wed, 04 Mar 2015 14:01:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FxmNvvAR56zYS07PgvNZzpueiEX4qD+yJ6q3xXEb7Sg=; b=TpDO2p7atd9ZdULxcY4E5e+qXUPnTuh9uBh8y9Vf6PRlstrmV43NqFI7szXyJYBM5F GRfwRM83HWNC0H6CdJTx+sdjwR/NkBje1x8SAAmEs6sEld/wLmq3tf2iOuyjmwXkYfzd pdZtZkcxcCKGeMmkuQaRRuRAexhHvGcuj9GVsMq23ldV3e+dd0mRzX93ev8XrV0mFlxr GEwG4zf3D9dqVi13TbE/LI18Bg40cMUHFtCD2/m0ATfLx+Wy8toP810Dwe0IS7GEFMzP SiMgTRCZJUijNgURtCMXw0/zi9TekuHZtnUi/s07XAuxUqzatW+G1fBjdouyREDU0NV1 YJeg== X-Gm-Message-State: ALoCoQkv0ACmNPZv7bU4V5K5JGrb7pgn7RHDraRAmjDIhq8MTkr4/JwtMselqhJuyUire6hJRLtc X-Received: by 10.194.9.98 with SMTP id y2mr12465283wja.85.1425506475798; Wed, 04 Mar 2015 14:01:15 -0800 (PST) Received: from [10.6.0.13] ([95.211.146.166]) by mx.google.com with ESMTPSA id hi6sm7705662wjc.34.2015.03.04.14.01.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 14:01:14 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DF7D6C50-4B5E-48F4-AF27-850D3066D48A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <54F71978.5090804@gmx.net> Date: Wed, 4 Mar 2015 23:01:14 +0100 Message-Id: References: <54F71978.5090804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 22:01:20 -0000 --Apple-Mail=_DF7D6C50-4B5E-48F4-AF27-850D3066D48A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 4, 2015, at 3:40 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > as the deadline is approaching I would like to close the open issues = of > the document. There are two open issues listed in the document and I > propose ways to resolve them below >=20 > Open Issue #1: >=20 > "In some conversations, we have said that it is the issuer of the JWT > that possesses the key, and in some conversations, we have said that > it is the presenter of the JWT that possesses the key. Which > description should we use? > " > The presenter=20 > There are the following parties in the entire picture (as the PoP > architecture document illustrates quite nicely): >=20 > * Issuer: Party that creates the JWT and binds a key to the token. > The key may be a symmetric key or a public key. To bind the key to the > JWT the issuer needs to compute a digital signature or a keyed message > digest over the JWT. >=20 > * Presenter: Party that demonstrates possession of a private key (for > asymmetric key cryptography) and secret key (for symmetric key > cryptography) to a recipient. >=20 > * Recipient: Party that receives the JWT together with the proof of > possession of the key (typically in form of a digital signature or a > keyed message digest). >=20 > Mapping this terminology to the OAuth context would look as follows: > - Issuer: OAuth Authorization Server > - Presenter: OAuth Client > - Recipient: OAuth Resource Server >=20 > Adding the above-mentioned terminology to the terminology section (and > deleting the currently listed presenter) would resolve the issue IMHO. >=20 That looks OK > Open Issue#2: >=20 > Mike added an editorial note to the introduction saying: > " > [[ Editorial Note: This paragraph needs to be updated to provide more > context and possibly also to describe the use of asymmetric keys > instead. It's not clear that the symmetric case is as useful or > valuable, and it is certainly more complicated.]] > " >=20 > The design team work clearly indicated that both symmetric and > asymmetric cryptography has to be supported. The JWT mechanism = actually > supports both and hence we should also describe both. What can, = however, > be done is to also describe the asymmetric key case and here is my = text > proposal for the introduction. >=20 Agreed we need both. > ---- > 1. Introduction >=20 > This specification defines how to bind a key to a JSON Web > Token (JWT) [JWT]. Three parties act in such a scenario: >=20 > * Issuer: Party that creates the JWT and binds a key to the token. > The key may be a symmetric key or a public key. To bind the key to > the JWT the issuer needs to compute a digital signature or a keyed > message digest over the JWT. >=20 > * Presenter: Party that demonstrates possession of a private key > (for asymmetric key cryptography) and secret key (for symmetric > key cryptography) to a recipient. This property is also sometimes > described as the presenter being a holder-of-key. >=20 > * Recipient: Party that receives the JWT together with the proof of > possession of the key (typically in form of a digital signature or a > keyed message digest). >=20 > [I-D.ietf-oauth-pop-architecture] describes the use of > proof-of-possession semantics for JSON Web Tokens (JWTs) for the use > with OAuth. >=20 > Envision the following two use cases. The first use case describes > the use of a symmetric key and the second use case focuses on > asymmetric cryptography. >=20 > An OAuth 2.0 authorization server generates a JWT > and places an encrypted symmetric key inside the newly introduced > confirmation claim. This symmetric key is encrypted with a key known > only to the authorization server and the recipient. The entire JWT > is then integrity protected. The JWT is then sent to the > presenter. Since the presenter is unable to obtain the > encrypted symmetric key from the JWT itself, the authorization > server conveys that symmetric key separately to the presenter. Now, > the presenter is in possession of the symmetric key as well as the > JWT (which includes the confirmation claim member). When the > presenter needs to present the JWT to the recipient, it also needs > to demonstrate possession of the symmetric key; the presenter, for > example, uses the symmetric key in a challenge/response protocol > with the recipient. The recipient is able to verify that it is > interacting with the genuine presenter by decrypting the JWK > contained inside the confirmation claim of the JWT. By doing this > the recipient obtains the symmetric key, which it then uses to > verify cryptographically protected messages exchanged with the > presenter. >=20 > This symmetric key mechanism described above is conceptually similar > to the use of Kerberos tickets. >=20 > In the second case consider a presenter that generates a public / > private key pair. It then sends the public key to an OAuth 2.0 > authorization server, which creates a JWT and places an public key > (or a fingerprint of it) inside the newly introduced confirmation > claim. The entire JWT is then integrity protected using a digital > signature to protect it against modifications. >=20 > The JWT is then sent to the presenter. When the presenter needs to > present the JWT to the recipient, it also needs to demonstrate > possession of the private key. The presenter, for example, uses the > private key in TLS exchange with the recipient. The recipient > is able to verify that it is interacting with the genuine presenter > by extracting the public key from the confirmation claim of the > JWT (after verifying the digital signature of the JWT) and utilizing > it with the private key in the TLS exchange. >=20 > The asymmetric key mechanism described above is conceptually similar > to a certificate. >=20 > In both cases the JWT may contain various claims that are included > based on the policy of the authorization server. >=20 In the asymmetric case if the client has a secure element having it = generate the key and send the keys=20 and sending public key to the AS is more secure than having the AS = generate it. We support both ways. I suppose it is OK to mention only one in the = introduction. I will spend some time on it now that MWC is almost over. John B. > ---- >=20 > Due to the IETF draft submission deadline we would appreciate a = response > by next Sunday. >=20 > Ciao > Hannes >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DF7D6C50-4B5E-48F4-AF27-850D3066D48A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMDQyMjAxMTVaMCMGCSqGSIb3DQEJBDEWBBTPzpJpinDrO9k2lEyyXzVp 5Mts7DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBFID9lfbUI7FgUxcNw5TQqeN5bzd7TbkCUiBqWgJSEjWbAL2NB4Esc eSKDLslJaFRNlJZORkZfER518uM/iKpMdU6rTJbGerPL0y22xRGqrBe0xdRVVMyhbP1EaAf0ly/X RsbHZ1bJvFNj0IrsMuMKbXvF4/Mu6KLN/6Gkvhw4znwY5yOp3hU9OoFOTcdVwTPvX28ErfFw0VPr 0L8sQul6hE8xuyarZt4v/jGULspSRDyt5BZ0ltO1kJrXy2ItDrToPPSSDxnYodKjLB2ZBDDMD7b9 nNkQeDmvz4hH8/RYg5cRw+rKaKKsf9AqRJTPWPivGhbNQtQlIAmVPp960KVEAAAAAAAA --Apple-Mail=_DF7D6C50-4B5E-48F4-AF27-850D3066D48A-- From nobody Wed Mar 4 14:54:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467511ACD11 for ; Wed, 4 Mar 2015 14:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 8sQP8YrhxFw9 for ; Wed, 4 Mar 2015 14:54:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90241ACD02 for ; Wed, 4 Mar 2015 14:54:13 -0800 (PST) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.99.14; Wed, 4 Mar 2015 22:54:12 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0099.004; Wed, 4 Mar 2015 22:54:12 +0000 From: Anthony Nadalin To: Justin Richer , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" Thread-Index: AQHQVaC55AXdo8duvUmNdgiBDVuri50M3fEAgAASWsA= Date: Wed, 4 Mar 2015 22:54:11 +0000 Message-ID: References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> In-Reply-To: <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: MIT.EDU; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(377454003)(53754006)(51914003)(24454002)(15584002)(86362001)(33656002)(76576001)(86612001)(76176999)(2900100001)(2950100001)(15975445007)(74316001)(16236675004)(15395725005)(19580405001)(2656002)(2171001)(19617315012)(19300405004)(62966003)(77156002)(40100003)(54356999)(46102003)(50986999)(92566002)(19609705001)(122556002)(19625215002)(99286002)(87936001)(102836002)(106116001)(19580395003)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0505147DDB Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234F02F7445797D08194424A61E0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2015 22:54:11.9075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 22:54:17 -0000 --_000_BN3PR0301MB1234F02F7445797D08194424A61E0BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlRoZSBkZWZpbml0aW9uIG9mIOKAnGFjdGl2ZeKAnSBpcyByZWFsbHkgdXAgdG8gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyLCBhbmQgSeKAmXZlIHlldCB0byBoZWFyIGZyb20gYW4gYWN0dWFsIGlt cGxlbWVudG9yIHdob+KAmXMgY29uZnVzZWQgYnkgdGhpcyBkZWZpbml0aW9uLiBXaGVuIHlvdeKA mXJlIHRoZSBvbmUgaXNzdWluZyB0aGUgdG9rZW5zLCB5b3Uga25vdyB3aGF0IGFuIOKAnGFjdGl2 ZeKAnSB0b2tlbiBtZWFucyB0byB5b3UNCg0KQWNjb3JkaW5nIHRvIHRoZSBzcGVjIGFzIHdyaXR0 ZW4gdGhlIEludHJvc3BlY3Rpb24gZW5kcG9pbnQgZG9lcyBub3QgaGF2ZSB0byBiZSBhbiBBdXRo b3JpemF0aW9uIFNldmVyIGFuZCB0aHVzIGVhY2ggY291bGQgaGF2ZSBkZWZpbmVkIOKAnGFjdGl2 ZeKAnSBpbiBkaWZmZXJlbnQgd2F5cw0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyDQpTZW50OiBXZWRuZXNkYXks IE1hcmNoIDQsIDIwMTUgMTo0NiBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogPG9hdXRo QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQWxpZ25tZW50IG9mIEpXVCBDbGFp bXMgYW5kIFRva2VuIEludHJvc3BlY3Rpb24gIkNsYWltcyINCg0KSGkgSGFubmVzLCB0aGFua3Mg Zm9yIHRoZSBmZWVkYmFjay4gUmVzcG9uc2VzIGlubGluZS4NCg0KT24gTWFyIDMsIDIwMTUsIGF0 IDU6NTYgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1h aWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQoNCkhpIEp1c3RpbiwgSGkg YWxsLA0KDQppbiBPQXV0aCB3ZSBwcm92aWRlIHR3byB3YXlzIGZvciBhIHJlc291cmNlIHNlcnZl ciB0byBtYWtlIGFuDQphdXRob3JpemF0aW9uIGRlY2lzaW9uLg0KDQoxKSBUaGUgcmVzb3VyY2Ug c2VydmVyIHJlY2VpdmVzIGEgc2VsZi1jb250YWluZWQgdG9rZW4gdGhhdCBjb250YWlucyBhbGwN CnRoZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gdG8gbWFrZSBhIGxvY2FsIGF1dGhvcml6YXRpb24g ZGVjaXNpb24uIFdpdGgNCnRoZSBKV1Qgd2UgaGF2ZSBjcmVhdGVkIHN1Y2ggYSBzdGFuZGFyZGl6 ZWQgaW5mb3JtYXRpb24gYW5kIGRhdGEgbW9kZWwuDQoNCjIpIFdpdGggYW4gYWNjZXNzIHJlcXVl c3QgZnJvbSBhIGNsaWVudCB0aGUgcmVzb3VyY2Ugc2VydmVyIGFza3MgdGhlDQphdXRob3JpemF0 aW9uIHNlcnZlciBmb3IgImhlbHAiLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcHJvdmlkZXMN CmluZm9ybWF0aW9uIHRoYXQgaGVscCBtYWtlIHRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9uLiBU aGlzIGlzIHRoZSB0b2tlbg0KaW50cm9zcGVjdGlvbiBhcHByb2FjaC4NCg0KSSBiZWxpZXZlIHRo ZSB0d28gYXBwcm9hY2hlcyBuZWVkIHRvIGJlIGFsaWduZWQgd2l0aCByZWdhcmQgdG8gdGhlDQpp bmZvcm1hdGlvbiBhbmQgdGhlIGRhdGEgbW9kZWwuIFNpbmNlIGJvdGggZG9jdW1lbnRzIGFscmVh ZHkgdXNlIEpTT04gYXMNCmEgd2F5IHRvIGVuY29kZSBpbmZvcm1hdGlvbiAoPWRhdGEgbW9kZWwp IGFuZCBhbG1vc3QgaGF2ZSBhbiBpZGVudGljYWwNCmluZm9ybWF0aW9uIG1vZGVsICh0aGUgZGF0 YSB0aGF0IGlzIGJlaW5nIHBhc3NlZCBhcm91bmQpLg0KDQpXaGF0IG5lZWRzIHRvIGJlIGRvbmU/ DQoNCiogVXNlIHRoZSB0ZXJtICdjbGFpbXMnIGluIGJvdGggZG9jdW1lbnRzLg0KKiBVc2UgdGhl IHNhbWUgcmVnaXN0cnkgKGkuZS4sIHRoZSByZWdpc3RyeSBlc3RhYmxpc2hlZCB3aXRoIHRoZSBK V1QpLg0KKiBSZWdpc3RlciB0aGUgbmV3bHkgZGVmaW5lZCBjbGFpbXMgZnJvbSB0aGUgdG9rZW4g aW50cm9zcGVjdGlvbg0KZG9jdW1lbnQgaW4gdGhlIGNsYWltcyByZWdpc3RyeS4NCg0KV2XigJl2 ZSBhbHJlYWR5IGRvbmUgdGhpcyBpbiB0aGUgbGF0ZXN0IGRyYWZ0LiBPciBhdCBsZWFzdCwgdGhh dOKAmXMgdGhlIGludGVudCBvZiB0aGUgY3VycmVudCB0ZXh0IOKAlCB0aGUgcmVnaXN0cnkgaXMg cmVmZXJlbmNlZCBhbmQgdGhlIG5ldyBjbGFpbXMgYXJlIHJlZ2lzdGVyZWQuIENhbiB5b3Ugc3Bl Y2lmaWNhbGx5IHBvaW50IHRvIHBsYWNlcyB3aGVyZSB0aGlzIG5lZWRzIHRvIGJlIGltcHJvdmVk IHVwb24/DQoNCg0KVGhlbiwgSSBoYXZlIGEgZmV3IGNvbW1lbnRzIG9uIHRoZSBuZXcgY2xhaW1z IHRoYXQgYXJlIHByb3Bvc2VkOg0KDQpIZXJlIGlzIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAnYWN0 aXZlJyBjbGFpbToNCg0KICBhY3RpdmUNCiAgICAgUkVRVUlSRUQuICBCb29sZWFuIGluZGljYXRv ciBvZiB3aGV0aGVyIG9yIG5vdCB0aGUgcHJlc2VudGVkIHRva2VuDQogICAgIGlzIGN1cnJlbnRs eSBhY3RpdmUuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGV0ZXJtaW5lcyB3aGV0aGVyDQog ICAgIGFuZCB3aGVuIGEgZ2l2ZW4gdG9rZW4gaXMgaW4gYW4gYWN0aXZlIHN0YXRlLg0KDQpUaGlz IGNsYWltIGlzIG5vdCB3ZWxsLWRlZmluZWQuIFlvdSBuZWVkIHRvIGV4cGxhaW4gd2hhdCAiYWN0 aXZlIiBtZWFucy4NCkl0IGNvdWxkLCBmb3IgZXhhbXBsZSwgbWVhbiB0aGF0IHRoZSB0b2tlbiBp cyBub3QgeWV0IGV4cGlyZWQuIFRoZW4sDQp0aGVyZSBpcyBvZiBjb3Vyc2UgdGhlIHF1ZXN0aW9u IHdoeSB5b3UgYXJlIG5vdCByZXR1cm5pbmcgdGhlICdleHAnDQpjbGFpbSB0b2dldGhlciB3aXRo IHRoZSAnbmJmJyBjbGFpbS4NCg0KVGhlIGRlZmluaXRpb24gb2Yg4oCcYWN0aXZl4oCdIGlzIHJl YWxseSB1cCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCBJ4oCZdmUgeWV0IHRvIGhl YXIgZnJvbSBhbiBhY3R1YWwgaW1wbGVtZW50b3Igd2hv4oCZcyBjb25mdXNlZCBieSB0aGlzIGRl ZmluaXRpb24uIFdoZW4geW914oCZcmUgdGhlIG9uZSBpc3N1aW5nIHRoZSB0b2tlbnMsIHlvdSBr bm93IHdoYXQgYW4g4oCcYWN0aXZl4oCdIHRva2VuIG1lYW5zIHRvIHlvdS4gU3RpbGwsIHBlcmhh cHMgd2UgY2FuIGJlIGV2ZW4gbW9yZSBleHBsaWNpdCwgc3VjaCBhczoNCg0KDQphY3RpdmUNCiAg UkVRVUlSRUQuIEJvb2xlYW4gaW5kaWNhdG9yIG9mIHdoZXRoZXIgb3Igbm90IHRoZSBwcmVzZW50 ZWQgdG9rZW4gaXMgY3VycmVudGx5IGFjdGl2ZS4gVGhlIHNwZWNpZmljcyBvZiBhIHRva2Vu4oCZ cyBhY3RpdmUgc3RhdGUgd2lsbCB2YXJ5IGRlcGVuZGluZyBvbiB0aGUgaW1wbGVtZW50YXRpb24g b2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBidXQgZ2VuZXJhbGx5IHRoaXMgd2lsbCBpbmRp Y2F0ZSB0aGF0IGEgZ2l2ZW4gdG9rZW4gaGFzIGJlZW4gaXNzdWVkIGJ5IHRoaXMgYXV0aG9yaXph dGlvbiBzZXJ2ZXIsIGhhcyBub3QgYmVlbiByZXZva2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lciwg YW5kIGlzIHdpdGhpbiBpdHMgZ2l2ZW4gdGltZSB3aW5kb3cgb2YgdmFsaWRpdHkgKGUuZy4gbm90 IGV4cGlyZWQpLg0KDQpBbHNvLCB0aGlzIGlzIG9uZSBvZiB0aGUgcGxhY2VzIHdoZXJlIHRoZSBv dmVybGFwIGJldHdlZW4gSldUIGFuZCBpbnRyb3NwZWN0aW9uIGNsYWltcyBkb27igJl0IG1ha2Ug c2Vuc2UuIEl0IGRvZXNu4oCZdCBtYWtlIGFueSBzZW5zZSBmb3IgYSBKV1QgdG8gY2FycnkgYW4g 4oCcYWN0aXZl4oCdIGNsYWltIGF0IGFsbC4gV2h5IHdvdWxkIHlvdSBoYXZlIGEgSldUIGNsYWlt IHRvIGJlIGFueXRoaW5nIGJ1dCBhY3RpdmU/IFdlIHNob3VsZCByZWdpc3RlciBpdCB3aXRoIHRo ZSBKV1QgcmVnaXN0cnkgdG8gYXZvaWQgbmFtZSBjb2xsaXNpb25zLCBidXQgdGhlcmXigJlzIG5v dGhpbmcgaW4gdGhlIEpXVCByZWdpc3RyeSB0aGF0IHNheXMg4oCcZG9u4oCZdCB1c2UgdGhpcyBp bnNpZGUgb2YgYSBKV1TigJ0uIERvIHlvdSBoYXZlIGFueSBhZHZpY2Ugb24gaG93IHRvIGFkZHJl c3MgdGhpcz8NCg0KDQoNCmNsaWVudF9pZDogV2hhdCBpcyB0aGUgcmVzb3VyY2Ugc2VydmVyIGdv aW5nIHRvIGRvIHdpdGggdGhlIGNsaWVudF9pZD8NCldoYXQgYXV0aG9yaXphdGlvbiBkZWNpc2lv biBjb3VsZCBpdCBtYWtlPw0KDQpXaGF0ZXZlciBpdCB3YW50cyB0by4gSWYgYW4gUlMgY2FuIGZp Z3VyZSBvdXQgc29tZXRoaW5nIGZyb20gdGhlIGNsaWVudF9pZCwgd2h5IG5vdCBsZXQgaXQ/IFRo ZSBjbGllbnRfaWQgaXMgYSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBv ZiB0aGUgaXNzdWFuY2Ugb2YgdGhlIHRva2VuLCBhbmQgYSBjb21tb24gZW5vdWdoIE9BdXRoIHZh bHVlIGZvciBkZWNpc2lvbiBtYWtpbmcuDQoNCg0KSSBoYXZlIGEgY291cGxlIG9mIHJlYWN0aW9u cyB3aGVuIEkgcmVhZCB0aGUgJ3VzZXJfaWQnIGNsYWltOg0KIC0gSSBiZWxpZXZlIHRoZSBpbmNs dXNpb24gb2YgYSB1c2VyIGlkIGZpZWxkIGluIHRoZSByZXNwb25zZSBjb3VsZA0KbGVhZCB0byBm dXJ0aGVyIGNvbmZ1c2lvbiByZWdhcmRpbmcgT0F1dGggYWNjZXNzIHRva2VuIHVzYWdlIGZvcg0K YXV0aGVudGljYXRpb24uDQoNClRoaXMgaXNu4oCZdCBhbnkgZGlmZmVyZW50IGZyb20gaGF2aW5n IGEgdXNlcmluZm8tZW5kcG9pbnQgZXF1aXZhbGVudCAobGlrZSBzb2NpYWwgZ3JhcGggb3IgdHdp dHRlciBBUEkpIGFuZCBpdOKAmXMgZ290IHRoZSBzYW1lIHRyb3VibGUuDQoNCg0KDQogLSBTaW5j ZSB5b3UgZGVmaW5lIGl0IGFzIGEgaHVtYW4gcmVhZGFibGUgaWRlbnRpZmllciBJIGFtIHdvbmRl cmluZw0Kd2hldGhlciB5b3Ugd2FudCB0byBzYXkgc29tZXRoaW5nIGFib3V0IHRoZSB1c2FnZS4g SGVyZSBpdCBzZWVtcyB0aGF0IGl0DQptaWdodCBiZSB1c2VkIGZvciBkaXNwbGF5aW5nIHNvbWV0 aGluZyBvbiBhIHdlYnBhZ2UgcmF0aGVyIHRoYW4gbWFraW5nDQphbiBhdXRob3JpemF0aW9uIGRl Y2lzaW9uIGJ1dCBJIG1pZ2h0IHdlbGwgYmUgd3JvbmcuDQoNCldlIGFkZGVkIGluIOKAnHVzZXJf aWTigJ0gdG8gb3VyIGltcGxlbWVudGF0aW9uIGR1ZSB0byBkZXZlbG9wZXIgZGVtYW5kIOKAlCB0 aGV5IHdhbnRlZCBhIHVzZXJuYW1lIGFzc29jaWF0ZWQgd2l0aCB0aGUgcmV0dXJuIHZhbHVlLCBi dXQgdG8gbGVhdmUgdGhlIOKAnHN1YuKAnSB2YWx1ZSB0aGUgc2FtZSBhcyB0aGF0IGRlZmluZWQg YnkgT3BlbklEIENvbm5lY3QuIE5vdGUgdGhhdCB0aGlzIGlzIGluIGFuIGVudmlyb25tZW50IHdo ZXJlIHRoZSB1c2VybmFtZSBpcyBhIGtub3duIHF1YW50aXR5LCBhbmQgdGhleeKAmXJlIG5vdCB0 cnlpbmcgdG8gZG8gY3Jvc3MtZG9tYWluIGF1dGhlbnRpY2F0aW9uLiBUaGV5IGp1c3Qgd2FudCB0 byBrbm93IHdob3NlIHRva2VuIHRoaXMgd2FzIHNvIHRoZXkgY2FuIGZpZ3VyZSBvdXQgd2hvc2Ug ZGF0YSB0byByZXR1cm4uIEl04oCZcyBub3QgdXNlZCBmb3IgZGlzcGxheSwgYnV0IEkgdHJpZWQg dG8gbWFrZSB0aGUgZGVmaW5pdGlvbiBpbiBjb250cmFzdCB0byB0aGUgbWFjaGluZS1mYWNpbmcg 4oCcc3Vi4oCdIHZhbHVlLg0KDQoNCg0KIC0gSSBhbSBtaXNzaW5nIGEgZGlzY3Vzc2lvbiBhYm91 dCB0aGUgcHJpdmFjeSBpbXBsaWNhdGlvbnMgb2YgaXQuDQpXaGlsZSB0aGVyZSBpcyBhIHByaXZh Y3kgY29uc2lkZXJhdGlvbiBzZWN0aW9uIEkgYW0gd29uZGVyaW5nIHdoYXQNCmNvbnRyb2xzIHRo ZSByZWxlYXNlIG9mIHRoaXMgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGZyb20gdGhlDQphdXRob3Jp emF0aW9uIHNlcnZlciB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLiBXaGlsZSBpbiBzb21lIGNhc2Vz IHRoZSB0d28NCnBhcnRpZXMgbWlnaHQgYmVsb25nIHRvIHRoZSBzYW1lIG9yZ2FuaXphdGlvbiBi dXQgaW4gb3RoZXIgY2FzZXMgdGhhdA0KbWF5IG5vdCBuZWNlc3NhcmlseSBiZSB0cnVlLg0KDQpZ b3XigJlyZSBjb3JyZWN0LCB0aGlzIGlzIGN1cnJlbnRseSBtaXNzaW5nIGFuZCBJ4oCZbGwgYWRk IHRoYXQgaW4uDQoNCg0KDQogLSBJbiB0ZXJtcyBvZiB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2Vk IGFib3V0IHRoZSB1c2VyIEkgYW0gY3VyaW91cw0KYWJvdXQgdGhlIHVzZWZ1bG5lc3Mgb2YgaW5j bHVkaW5nIG90aGVyIGluZm9ybWF0aW9uIGFzIHdlbGwsIHN1Y2ggYXMgdGhlDQppbmZvIHRoYXQg aXMgaW5jbHVkZWQgaW4gYW4gaWQgdG9rZW4gKHNlZQ0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mv b3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNJRFRva2VuKS4gSWYgdGhpcw0KaGFzIG5vdGhp bmcgdG8gZG8gd2l0aCB0aGUgSUQgdG9rZW4gY29uY2VwdCBhbmQgdGhlIGluZm9ybWF0aW9uIGNh cnJpZWQNCndpdGhpbiBpdCB0aGVuIEkgd291bGQgYWRkIHRoYXQgcmVtYXJrLg0KDQoNCllvdSBj b3VsZCBpbnRyb3NwZWN0IGFuIElEIHRva2VuIGlmIHlvdSB3YW50ZWQgdG8sIGJ1dCBpdOKAmXMg dXN1YWxseSBlYXNpZXIgdG8ganVzdCBwYXJzZSBpdCB5b3Vyc2VsZiBiZWNhdXNlIGl04oCZcyBz ZWxmLWNvbnRhaW5lZC4gVGhlIElEIFRva2VuIGFsc28gZXh0ZW5kcyBKV1QsIHNvIHRoZXJl4oCZ cyBub3RoaW5nIHN0b3BwaW5nIHlvdSBmcm9tIHJldHVybmluZyB0aG9zZSBjbGFpbXMgYXMgd2Vs bC4gSG93ZXZlciwgbm90ZSB0aGF0IHRoZSBhdWRpZW5jZSBvZiB0aGUgSUQgdG9rZW4gaXMgdGhl IE9BdXRoICpjbGllbnQqIHdoZXJlYXMgdGhlIHRhcmdldGVkIHVzZXIgb2YgdGhlIGludHJvc3Bl Y3Rpb24gZW5kcG9pbnQgaXMgdGhlICpwcm90ZWN0ZWQgcmVzb3VyY2UqLiBUaGUgUFIgaXNu4oCZ dCBnb2luZyB0byBzZWUgdGhlIElEIFRva2VuIG1vc3Qgb2YgdGhlIHRpbWUsIGFuZCB0aGUgY2xp ZW504oCZcyBub3QgZ29pbmcgdG8gbmVlZCB0byAob3IgYmUgYWJsZSB0bykgaW50cm9zcGVjdCBp dHMgdG9rZW5zIG1vc3Qgb2YgdGhlIHRpbWUsIHNvIGluIHByYWN0aWNlIHRoZXJl4oCZcyBub3Qg cmVhbGx5IGFueSBvdmVybGFwLg0KDQog4oCUIEp1c3Rpbg0KDQoNCg0KQ2lhbw0KSGFubmVzDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_BN3PR0301MB1234F02F7445797D08194424A61E0BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5UaGUgZGVmaW5pdGlvbiBvZiDigJxhY3RpdmXigJ0g aXMgcmVhbGx5IHVwIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIEnigJl2ZSB5ZXQg dG8gaGVhciBmcm9tIGFuIGFjdHVhbCBpbXBsZW1lbnRvciB3aG/igJlzIGNvbmZ1c2VkIGJ5IHRo aXMgZGVmaW5pdGlvbi4NCiBXaGVuIHlvdeKAmXJlIHRoZSBvbmUgaXNzdWluZyB0aGUgdG9rZW5z LCB5b3Uga25vdyB3aGF0IGFuIOKAnGFjdGl2ZeKAnSB0b2tlbiBtZWFucyB0byB5b3U8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWNjb3JkaW5nIHRvIHRoZSBzcGVjIGFzIHdy aXR0ZW4gdGhlIEludHJvc3BlY3Rpb24gZW5kcG9pbnQgZG9lcyBub3QgaGF2ZSB0byBiZSBhbiBB dXRob3JpemF0aW9uIFNldmVyIGFuZCB0aHVzIGVhY2ggY291bGQgaGF2ZSBkZWZpbmVkIOKAnGFj dGl2ZeKAnSBpbiBkaWZmZXJlbnQNCiB3YXlzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gUmlj aGVyPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggNCwgMjAxNSAxOjQ2IFBNPGJy Pg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCjxiPkNjOjwvYj4gJmx0O29hdXRo QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBbGlnbm1l bnQgb2YgSldUIENsYWltcyBhbmQgVG9rZW4gSW50cm9zcGVjdGlvbiAmcXVvdDtDbGFpbXMmcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBIYW5u ZXMsIHRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBSZXNwb25zZXMgaW5saW5lLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAzLCAyMDE1LCBhdCA1 OjU2IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2No b2ZlbmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5IaSBKdXN0aW4sIEhpIGFsbCw8YnI+DQo8YnI+DQppbiBPQXV0aCB3ZSBwcm92 aWRlIHR3byB3YXlzIGZvciBhIHJlc291cmNlIHNlcnZlciB0byBtYWtlIGFuPGJyPg0KYXV0aG9y aXphdGlvbiBkZWNpc2lvbi48YnI+DQo8YnI+DQoxKSBUaGUgcmVzb3VyY2Ugc2VydmVyIHJlY2Vp dmVzIGEgc2VsZi1jb250YWluZWQgdG9rZW4gdGhhdCBjb250YWlucyBhbGw8YnI+DQp0aGUgbmVj ZXNzYXJ5IGluZm9ybWF0aW9uIHRvIG1ha2UgYSBsb2NhbCBhdXRob3JpemF0aW9uIGRlY2lzaW9u LiBXaXRoPGJyPg0KdGhlIEpXVCB3ZSBoYXZlIGNyZWF0ZWQgc3VjaCBhIHN0YW5kYXJkaXplZCBp bmZvcm1hdGlvbiBhbmQgZGF0YSBtb2RlbC48YnI+DQo8YnI+DQoyKSBXaXRoIGFuIGFjY2VzcyBy ZXF1ZXN0IGZyb20gYSBjbGllbnQgdGhlIHJlc291cmNlIHNlcnZlciBhc2tzIHRoZTxicj4NCmF1 dGhvcml6YXRpb24gc2VydmVyIGZvciAmcXVvdDtoZWxwJnF1b3Q7LiBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgcHJvdmlkZXM8YnI+DQppbmZvcm1hdGlvbiB0aGF0IGhlbHAgbWFrZSB0aGUgYXV0 aG9yaXphdGlvbiBkZWNpc2lvbi4gVGhpcyBpcyB0aGUgdG9rZW48YnI+DQppbnRyb3NwZWN0aW9u IGFwcHJvYWNoLjxicj4NCjxicj4NCkkgYmVsaWV2ZSB0aGUgdHdvIGFwcHJvYWNoZXMgbmVlZCB0 byBiZSBhbGlnbmVkIHdpdGggcmVnYXJkIHRvIHRoZTxicj4NCmluZm9ybWF0aW9uIGFuZCB0aGUg ZGF0YSBtb2RlbC4gU2luY2UgYm90aCBkb2N1bWVudHMgYWxyZWFkeSB1c2UgSlNPTiBhczxicj4N CmEgd2F5IHRvIGVuY29kZSBpbmZvcm1hdGlvbiAoPWRhdGEgbW9kZWwpIGFuZCBhbG1vc3QgaGF2 ZSBhbiBpZGVudGljYWw8YnI+DQppbmZvcm1hdGlvbiBtb2RlbCAodGhlIGRhdGEgdGhhdCBpcyBi ZWluZyBwYXNzZWQgYXJvdW5kKS48YnI+DQo8YnI+DQpXaGF0IG5lZWRzIHRvIGJlIGRvbmU/PGJy Pg0KPGJyPg0KKiBVc2UgdGhlIHRlcm0gJ2NsYWltcycgaW4gYm90aCBkb2N1bWVudHMuPGJyPg0K KiBVc2UgdGhlIHNhbWUgcmVnaXN0cnkgKGkuZS4sIHRoZSByZWdpc3RyeSBlc3RhYmxpc2hlZCB3 aXRoIHRoZSBKV1QpLjxicj4NCiogUmVnaXN0ZXIgdGhlIG5ld2x5IGRlZmluZWQgY2xhaW1zIGZy b20gdGhlIHRva2VuIGludHJvc3BlY3Rpb248YnI+DQpkb2N1bWVudCBpbiB0aGUgY2xhaW1zIHJl Z2lzdHJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZeKAmXZlIGFscmVhZHkgZG9uZSB0aGlzIGluIHRoZSBsYXRl c3QgZHJhZnQuIE9yIGF0IGxlYXN0LCB0aGF04oCZcyB0aGUgaW50ZW50IG9mIHRoZSBjdXJyZW50 IHRleHQg4oCUIHRoZSByZWdpc3RyeSBpcyByZWZlcmVuY2VkIGFuZCB0aGUgbmV3IGNsYWltcyBh cmUgcmVnaXN0ZXJlZC4gQ2FuIHlvdSBzcGVjaWZpY2FsbHkgcG9pbnQgdG8gcGxhY2VzIHdoZXJl IHRoaXMgbmVlZHMgdG8gYmUgaW1wcm92ZWQgdXBvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVuLCBJIGhhdmUgYSBmZXcgY29tbWVudHMgb24gdGhl IG5ldyBjbGFpbXMgdGhhdCBhcmUgcHJvcG9zZWQ6PGJyPg0KPGJyPg0KSGVyZSBpcyB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgJ2FjdGl2ZScgY2xhaW06PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7YWN0 aXZlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UkVRVUlSRUQuICZuYnNwO0Jv b2xlYW4gaW5kaWNhdG9yIG9mIHdoZXRoZXIgb3Igbm90IHRoZSBwcmVzZW50ZWQgdG9rZW48YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpcyBjdXJyZW50bHkgYWN0aXZlLiAmbmJz cDtUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGV0ZXJtaW5lcyB3aGV0aGVyPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIHdoZW4gYSBnaXZlbiB0b2tlbiBpcyBpbiBhbiBh Y3RpdmUgc3RhdGUuPGJyPg0KPGJyPg0KVGhpcyBjbGFpbSBpcyBub3Qgd2VsbC1kZWZpbmVkLiBZ b3UgbmVlZCB0byBleHBsYWluIHdoYXQgJnF1b3Q7YWN0aXZlJnF1b3Q7IG1lYW5zLjxicj4NCkl0 IGNvdWxkLCBmb3IgZXhhbXBsZSwgbWVhbiB0aGF0IHRoZSB0b2tlbiBpcyBub3QgeWV0IGV4cGly ZWQuIFRoZW4sPGJyPg0KdGhlcmUgaXMgb2YgY291cnNlIHRoZSBxdWVzdGlvbiB3aHkgeW91IGFy ZSBub3QgcmV0dXJuaW5nIHRoZSAnZXhwJzxicj4NCmNsYWltIHRvZ2V0aGVyIHdpdGggdGhlICdu YmYnIGNsYWltLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZGVmaW5pdGlvbiBvZiDigJxhY3RpdmXigJ0gaXMg cmVhbGx5IHVwIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIEnigJl2ZSB5ZXQgdG8g aGVhciBmcm9tIGFuIGFjdHVhbCBpbXBsZW1lbnRvciB3aG/igJlzIGNvbmZ1c2VkIGJ5IHRoaXMg ZGVmaW5pdGlvbi4gV2hlbiB5b3XigJlyZSB0aGUgb25lIGlzc3VpbmcgdGhlIHRva2VucywgeW91 IGtub3cgd2hhdCBhbiDigJxhY3RpdmXigJ0gdG9rZW4gbWVhbnMgdG8geW91Lg0KIFN0aWxsLCBw ZXJoYXBzIHdlIGNhbiBiZSBldmVuIG1vcmUgZXhwbGljaXQsIHN1Y2ggYXM6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hY3RpdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyBSRVFVSVJFRC4gQm9vbGVhbiBpbmRpY2F0b3Igb2Ygd2hldGhlciBvciBu b3QgdGhlIHByZXNlbnRlZCB0b2tlbiBpcyBjdXJyZW50bHkgYWN0aXZlLiBUaGUgc3BlY2lmaWNz IG9mIGEgdG9rZW7igJlzIGFjdGl2ZSBzdGF0ZSB3aWxsIHZhcnkgZGVwZW5kaW5nIG9uIHRoZSBp bXBsZW1lbnRhdGlvbiBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGJ1dCBnZW5lcmFsbHkg dGhpcyB3aWxsIGluZGljYXRlIHRoYXQNCiBhIGdpdmVuIHRva2VuIGhhcyBiZWVuIGlzc3VlZCBi eSB0aGlzIGF1dGhvcml6YXRpb24gc2VydmVyLCBoYXMgbm90IGJlZW4gcmV2b2tlZCBieSB0aGUg cmVzb3VyY2Ugb3duZXIsIGFuZCBpcyB3aXRoaW4gaXRzIGdpdmVuIHRpbWUgd2luZG93IG9mIHZh bGlkaXR5IChlLmcuIG5vdCBleHBpcmVkKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbHNvLCB0aGlzIGlzIG9uZSBvZiB0aGUgcGxhY2VzIHdoZXJlIHRoZSBvdmVybGFwIGJldHdl ZW4gSldUIGFuZCBpbnRyb3NwZWN0aW9uIGNsYWltcyBkb27igJl0IG1ha2Ugc2Vuc2UuIEl0IGRv ZXNu4oCZdCBtYWtlIGFueSBzZW5zZSBmb3IgYSBKV1QgdG8gY2FycnkgYW4g4oCcYWN0aXZl4oCd IGNsYWltIGF0IGFsbC4gV2h5IHdvdWxkIHlvdSBoYXZlIGEgSldUIGNsYWltIHRvIGJlIGFueXRo aW5nIGJ1dCBhY3RpdmU/IFdlDQogc2hvdWxkIHJlZ2lzdGVyIGl0IHdpdGggdGhlIEpXVCByZWdp c3RyeSB0byBhdm9pZCBuYW1lIGNvbGxpc2lvbnMsIGJ1dCB0aGVyZeKAmXMgbm90aGluZyBpbiB0 aGUgSldUIHJlZ2lzdHJ5IHRoYXQgc2F5cyDigJxkb27igJl0IHVzZSB0aGlzIGluc2lkZSBvZiBh IEpXVOKAnS4gRG8geW91IGhhdmUgYW55IGFkdmljZSBvbiBob3cgdG8gYWRkcmVzcyB0aGlzPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCmNsaWVu dF9pZDogV2hhdCBpcyB0aGUgcmVzb3VyY2Ugc2VydmVyIGdvaW5nIHRvIGRvIHdpdGggdGhlIGNs aWVudF9pZD88YnI+DQpXaGF0IGF1dGhvcml6YXRpb24gZGVjaXNpb24gY291bGQgaXQgbWFrZT88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2hhdGV2ZXIgaXQgd2FudHMgdG8uIElmIGFuIFJTIGNhbiBmaWd1cmUgb3V0 IHNvbWV0aGluZyBmcm9tIHRoZSBjbGllbnRfaWQsIHdoeSBub3QgbGV0IGl0PyBUaGUgY2xpZW50 X2lkIGlzIGEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbnRleHQgb2YgdGhlIGlz c3VhbmNlIG9mIHRoZSB0b2tlbiwgYW5kIGEgY29tbW9uIGVub3VnaCBPQXV0aCB2YWx1ZSBmb3Ig ZGVjaXNpb24gbWFraW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGNvdXBsZSBvZiByZWFjdGlvbnMgd2hlbiBJIHJlYWQgdGhl ICd1c2VyX2lkJyBjbGFpbTo8YnI+DQombmJzcDstIEkgYmVsaWV2ZSB0aGUgaW5jbHVzaW9uIG9m IGEgdXNlciBpZCBmaWVsZCBpbiB0aGUgcmVzcG9uc2UgY291bGQ8YnI+DQpsZWFkIHRvIGZ1cnRo ZXIgY29uZnVzaW9uIHJlZ2FyZGluZyBPQXV0aCBhY2Nlc3MgdG9rZW4gdXNhZ2UgZm9yPGJyPg0K YXV0aGVudGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXNu4oCZdCBhbnkgZGlmZmVyZW50IGZy b20gaGF2aW5nIGEgdXNlcmluZm8tZW5kcG9pbnQgZXF1aXZhbGVudCAobGlrZSBzb2NpYWwgZ3Jh cGggb3IgdHdpdHRlciBBUEkpIGFuZCBpdOKAmXMgZ290IHRoZSBzYW1lIHRyb3VibGUuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5i c3A7LSBTaW5jZSB5b3UgZGVmaW5lIGl0IGFzIGEgaHVtYW4gcmVhZGFibGUgaWRlbnRpZmllciBJ IGFtIHdvbmRlcmluZzxicj4NCndoZXRoZXIgeW91IHdhbnQgdG8gc2F5IHNvbWV0aGluZyBhYm91 dCB0aGUgdXNhZ2UuIEhlcmUgaXQgc2VlbXMgdGhhdCBpdDxicj4NCm1pZ2h0IGJlIHVzZWQgZm9y IGRpc3BsYXlpbmcgc29tZXRoaW5nIG9uIGEgd2VicGFnZSByYXRoZXIgdGhhbiBtYWtpbmc8YnI+ DQphbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGJ1dCBJIG1pZ2h0IHdlbGwgYmUgd3JvbmcuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlIGFkZGVkIGluIOKAnHVzZXJfaWTigJ0gdG8gb3VyIGltcGxlbWVudGF0aW9u IGR1ZSB0byBkZXZlbG9wZXIgZGVtYW5kIOKAlCB0aGV5IHdhbnRlZCBhIHVzZXJuYW1lIGFzc29j aWF0ZWQgd2l0aCB0aGUgcmV0dXJuIHZhbHVlLCBidXQgdG8gbGVhdmUgdGhlIOKAnHN1YuKAnSB2 YWx1ZSB0aGUgc2FtZSBhcyB0aGF0IGRlZmluZWQgYnkgT3BlbklEIENvbm5lY3QuIE5vdGUgdGhh dCB0aGlzIGlzIGluIGFuIGVudmlyb25tZW50DQogd2hlcmUgdGhlIHVzZXJuYW1lIGlzIGEga25v d24gcXVhbnRpdHksIGFuZCB0aGV54oCZcmUgbm90IHRyeWluZyB0byBkbyBjcm9zcy1kb21haW4g YXV0aGVudGljYXRpb24uIFRoZXkganVzdCB3YW50IHRvIGtub3cgd2hvc2UgdG9rZW4gdGhpcyB3 YXMgc28gdGhleSBjYW4gZmlndXJlIG91dCB3aG9zZSBkYXRhIHRvIHJldHVybi4gSXTigJlzIG5v dCB1c2VkIGZvciBkaXNwbGF5LCBidXQgSSB0cmllZCB0byBtYWtlIHRoZSBkZWZpbml0aW9uIGlu IGNvbnRyYXN0DQogdG8gdGhlIG1hY2hpbmUtZmFjaW5nIOKAnHN1YuKAnSB2YWx1ZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDstIEkg YW0gbWlzc2luZyBhIGRpc2N1c3Npb24gYWJvdXQgdGhlIHByaXZhY3kgaW1wbGljYXRpb25zIG9m IGl0Ljxicj4NCldoaWxlIHRoZXJlIGlzIGEgcHJpdmFjeSBjb25zaWRlcmF0aW9uIHNlY3Rpb24g SSBhbSB3b25kZXJpbmcgd2hhdDxicj4NCmNvbnRyb2xzIHRoZSByZWxlYXNlIG9mIHRoaXMgc2Vu c2l0aXZlIGluZm9ybWF0aW9uIGZyb20gdGhlPGJyPg0KYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8g dGhlIHJlc291cmNlIHNlcnZlci4gV2hpbGUgaW4gc29tZSBjYXNlcyB0aGUgdHdvPGJyPg0KcGFy dGllcyBtaWdodCBiZWxvbmcgdG8gdGhlIHNhbWUgb3JnYW5pemF0aW9uIGJ1dCBpbiBvdGhlciBj YXNlcyB0aGF0PGJyPg0KbWF5IG5vdCBuZWNlc3NhcmlseSBiZSB0cnVlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z b3XigJlyZSBjb3JyZWN0LCB0aGlzIGlzIGN1cnJlbnRseSBtaXNzaW5nIGFuZCBJ4oCZbGwgYWRk IHRoYXQgaW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KJm5ic3A7LSBJbiB0ZXJtcyBvZiB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGFib3V0 IHRoZSB1c2VyIEkgYW0gY3VyaW91czxicj4NCmFib3V0IHRoZSB1c2VmdWxuZXNzIG9mIGluY2x1 ZGluZyBvdGhlciBpbmZvcm1hdGlvbiBhcyB3ZWxsLCBzdWNoIGFzIHRoZTxicj4NCmluZm8gdGhh dCBpcyBpbmNsdWRlZCBpbiBhbiBpZCB0b2tlbiAoc2VlPGJyPg0KPGEgaHJlZj0iaHR0cDovL29w ZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNJRFRva2VuIj5odHRw Oi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sI0lEVG9rZW48 L2E+KS4gSWYgdGhpczxicj4NCmhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIElEIHRva2VuIGNv bmNlcHQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjYXJyaWVkPGJyPg0Kd2l0aGluIGl0IHRoZW4gSSB3 b3VsZCBhZGQgdGhhdCByZW1hcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGNvdWxkIGludHJvc3BlY3Qg YW4gSUQgdG9rZW4gaWYgeW91IHdhbnRlZCB0bywgYnV0IGl04oCZcyB1c3VhbGx5IGVhc2llciB0 byBqdXN0IHBhcnNlIGl0IHlvdXJzZWxmIGJlY2F1c2UgaXTigJlzIHNlbGYtY29udGFpbmVkLiBU aGUgSUQgVG9rZW4gYWxzbyBleHRlbmRzIEpXVCwgc28gdGhlcmXigJlzIG5vdGhpbmcgc3RvcHBp bmcgeW91IGZyb20gcmV0dXJuaW5nIHRob3NlIGNsYWltcyBhcyB3ZWxsLiBIb3dldmVyLA0KIG5v dGUgdGhhdCB0aGUgYXVkaWVuY2Ugb2YgdGhlIElEIHRva2VuIGlzIHRoZSBPQXV0aCAqY2xpZW50 KiB3aGVyZWFzIHRoZSB0YXJnZXRlZCB1c2VyIG9mIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50 IGlzIHRoZSAqcHJvdGVjdGVkIHJlc291cmNlKi4gVGhlIFBSIGlzbuKAmXQgZ29pbmcgdG8gc2Vl IHRoZSBJRCBUb2tlbiBtb3N0IG9mIHRoZSB0aW1lLCBhbmQgdGhlIGNsaWVudOKAmXMgbm90IGdv aW5nIHRvIG5lZWQgdG8gKG9yIGJlIGFibGUgdG8pDQogaW50cm9zcGVjdCBpdHMgdG9rZW5zIG1v c3Qgb2YgdGhlIHRpbWUsIHNvIGluIHByYWN0aWNlIHRoZXJl4oCZcyBub3QgcmVhbGx5IGFueSBv dmVybGFwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KQ2lhbzxicj4NCkhhbm5lczxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BN3PR0301MB1234F02F7445797D08194424A61E0BN3PR0301MB1234_-- From nobody Wed Mar 4 15:25:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC481A0053 for ; Wed, 4 Mar 2015 15:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Eq8khETGwOc9 for ; Wed, 4 Mar 2015 15:25:53 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95031A004A for ; Wed, 4 Mar 2015 15:25:52 -0800 (PST) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (25.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.99.14; Wed, 4 Mar 2015 23:25:51 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0099.004; Wed, 4 Mar 2015 23:25:50 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline Thread-Index: AQHQVolBYKU2iEv0rEGFakA1XyRiFJ0M93/w Date: Wed, 4 Mar 2015 23:25:50 +0000 Message-ID: References: <54F71978.5090804@gmx.net> In-Reply-To: <54F71978.5090804@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: gmx.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(53754006)(86612001)(19580395003)(86362001)(122556002)(54356999)(2950100001)(62966003)(46102003)(2501003)(77156002)(19580405001)(76176999)(40100003)(50986999)(92566002)(33656002)(2900100001)(561944003)(74316001)(230783001)(99286002)(2656002)(87936001)(106116001)(76576001)(102836002)(107886001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 0505147DDB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2015 23:25:50.3196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 23:25:55 -0000 V2h5IGRvZXMgdGhlIHNwZWNpZmljYXRpb24gc3RhdGUgImVuY3J5cHRlZCB0byBhIGtleSBrbm93 biB0byB0aGUgcmVjaXBpZW50IHVzaW5nIHRoZSBKV0UgQ29tcGFjdCBTZXJpYWxpemF0aW9uIiBp cyB0aGlzIHRoZSBvbmx5IHNlcmlhbGl6YXRpb24gYWxsb3dlZCAodGhlcmUgaXMgbm8gTVVTVCkg Pw0KY29udGFpbmluZyB0aGUgc3ltbWV0cmljIGtleS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDQsIDIwMTUg Njo0MSBBTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbT0FVVEgtV0ddIGRyYWZ0LWll dGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wMTogQ2xvc2luZyBPcGVuIElzc3VlcyBiZWZv cmUgdGhlIERlYWRsaW5lDQoNCkhpIGFsbCwNCg0KYXMgdGhlIGRlYWRsaW5lIGlzIGFwcHJvYWNo aW5nIEkgd291bGQgbGlrZSB0byBjbG9zZSB0aGUgb3BlbiBpc3N1ZXMgb2YgdGhlIGRvY3VtZW50 LiBUaGVyZSBhcmUgdHdvIG9wZW4gaXNzdWVzIGxpc3RlZCBpbiB0aGUgZG9jdW1lbnQgYW5kIEkg cHJvcG9zZSB3YXlzIHRvIHJlc29sdmUgdGhlbSBiZWxvdw0KDQpPcGVuIElzc3VlICMxOg0KDQoi SW4gc29tZSBjb252ZXJzYXRpb25zLCB3ZSBoYXZlIHNhaWQgdGhhdCBpdCBpcyB0aGUgaXNzdWVy IG9mIHRoZSBKV1QNCiAgIHRoYXQgcG9zc2Vzc2VzIHRoZSBrZXksIGFuZCBpbiBzb21lIGNvbnZl cnNhdGlvbnMsIHdlIGhhdmUgc2FpZCB0aGF0DQogICBpdCBpcyB0aGUgcHJlc2VudGVyIG9mIHRo ZSBKV1QgdGhhdCBwb3NzZXNzZXMgdGhlIGtleS4gIFdoaWNoDQogICBkZXNjcmlwdGlvbiBzaG91 bGQgd2UgdXNlPw0KIg0KDQpUaGVyZSBhcmUgdGhlIGZvbGxvd2luZyBwYXJ0aWVzIGluIHRoZSBl bnRpcmUgcGljdHVyZSAoYXMgdGhlIFBvUCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaWxsdXN0cmF0 ZXMgcXVpdGUgbmljZWx5KToNCg0KKiBJc3N1ZXI6IFBhcnR5IHRoYXQgY3JlYXRlcyB0aGUgSldU IGFuZCBiaW5kcyBhIGtleSB0byB0aGUgdG9rZW4uDQpUaGUga2V5IG1heSBiZSBhIHN5bW1ldHJp YyBrZXkgb3IgYSBwdWJsaWMga2V5LiBUbyBiaW5kIHRoZSBrZXkgdG8gdGhlIEpXVCB0aGUgaXNz dWVyIG5lZWRzIHRvIGNvbXB1dGUgYSBkaWdpdGFsIHNpZ25hdHVyZSBvciBhIGtleWVkIG1lc3Nh Z2UgZGlnZXN0IG92ZXIgdGhlIEpXVC4NCg0KKiBQcmVzZW50ZXI6IFBhcnR5IHRoYXQgZGVtb25z dHJhdGVzIHBvc3Nlc3Npb24gb2YgYSBwcml2YXRlIGtleSAoZm9yIGFzeW1tZXRyaWMga2V5IGNy eXB0b2dyYXBoeSkgYW5kIHNlY3JldCBrZXkgKGZvciBzeW1tZXRyaWMga2V5DQpjcnlwdG9ncmFw aHkpIHRvIGEgcmVjaXBpZW50Lg0KDQoqIFJlY2lwaWVudDogUGFydHkgdGhhdCByZWNlaXZlcyB0 aGUgSldUIHRvZ2V0aGVyIHdpdGggdGhlIHByb29mIG9mIHBvc3Nlc3Npb24gb2YgdGhlIGtleSAo dHlwaWNhbGx5IGluIGZvcm0gb2YgYSBkaWdpdGFsIHNpZ25hdHVyZSBvciBhIGtleWVkIG1lc3Nh Z2UgZGlnZXN0KS4NCg0KTWFwcGluZyB0aGlzIHRlcm1pbm9sb2d5IHRvIHRoZSBPQXV0aCBjb250 ZXh0IHdvdWxkIGxvb2sgYXMgZm9sbG93czoNCiAtIElzc3VlcjogT0F1dGggQXV0aG9yaXphdGlv biBTZXJ2ZXINCiAtIFByZXNlbnRlcjogT0F1dGggQ2xpZW50DQogLSBSZWNpcGllbnQ6IE9BdXRo IFJlc291cmNlIFNlcnZlcg0KDQpBZGRpbmcgdGhlIGFib3ZlLW1lbnRpb25lZCB0ZXJtaW5vbG9n eSB0byB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiAoYW5kIGRlbGV0aW5nIHRoZSBjdXJyZW50bHkg bGlzdGVkIHByZXNlbnRlcikgd291bGQgcmVzb2x2ZSB0aGUgaXNzdWUgSU1ITy4NCg0KT3BlbiBJ c3N1ZSMyOg0KDQpNaWtlIGFkZGVkIGFuIGVkaXRvcmlhbCBub3RlIHRvIHRoZSBpbnRyb2R1Y3Rp b24gc2F5aW5nOg0KIg0KIFtbIEVkaXRvcmlhbCBOb3RlOiBUaGlzIHBhcmFncmFwaCBuZWVkcyB0 byBiZSB1cGRhdGVkIHRvIHByb3ZpZGUgbW9yZQ0KICAgY29udGV4dCBhbmQgcG9zc2libHkgYWxz byB0byBkZXNjcmliZSB0aGUgdXNlIG9mIGFzeW1tZXRyaWMga2V5cw0KICAgaW5zdGVhZC4gIEl0 J3Mgbm90IGNsZWFyIHRoYXQgdGhlIHN5bW1ldHJpYyBjYXNlIGlzIGFzIHVzZWZ1bCBvcg0KICAg dmFsdWFibGUsIGFuZCBpdCBpcyBjZXJ0YWlubHkgbW9yZSBjb21wbGljYXRlZC5dXSAiDQoNClRo ZSBkZXNpZ24gdGVhbSB3b3JrIGNsZWFybHkgaW5kaWNhdGVkIHRoYXQgYm90aCBzeW1tZXRyaWMg YW5kIGFzeW1tZXRyaWMgY3J5cHRvZ3JhcGh5IGhhcyB0byBiZSBzdXBwb3J0ZWQuIFRoZSBKV1Qg bWVjaGFuaXNtIGFjdHVhbGx5IHN1cHBvcnRzIGJvdGggYW5kIGhlbmNlIHdlIHNob3VsZCBhbHNv IGRlc2NyaWJlIGJvdGguIFdoYXQgY2FuLCBob3dldmVyLCBiZSBkb25lIGlzIHRvIGFsc28gZGVz Y3JpYmUgdGhlIGFzeW1tZXRyaWMga2V5IGNhc2UgYW5kIGhlcmUgaXMgbXkgdGV4dCBwcm9wb3Nh bCBmb3IgdGhlIGludHJvZHVjdGlvbi4NCg0KLS0tLQ0KMS4gIEludHJvZHVjdGlvbg0KDQogICBU aGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBob3cgdG8gYmluZCBhIGtleSB0byBhIEpTT04gV2Vi DQogICBUb2tlbiAoSldUKSBbSldUXS4gVGhyZWUgcGFydGllcyBhY3QgaW4gc3VjaCBhIHNjZW5h cmlvOg0KDQoqIElzc3VlcjogUGFydHkgdGhhdCBjcmVhdGVzIHRoZSBKV1QgYW5kIGJpbmRzIGEg a2V5IHRvIHRoZSB0b2tlbi4NClRoZSBrZXkgbWF5IGJlIGEgc3ltbWV0cmljIGtleSBvciBhIHB1 YmxpYyBrZXkuIFRvIGJpbmQgdGhlIGtleSB0byB0aGUgSldUIHRoZSBpc3N1ZXIgbmVlZHMgdG8g Y29tcHV0ZSBhIGRpZ2l0YWwgc2lnbmF0dXJlIG9yIGEga2V5ZWQgbWVzc2FnZSBkaWdlc3Qgb3Zl ciB0aGUgSldULg0KDQoqIFByZXNlbnRlcjogUGFydHkgdGhhdCBkZW1vbnN0cmF0ZXMgcG9zc2Vz c2lvbiBvZiBhIHByaXZhdGUga2V5IChmb3IgYXN5bW1ldHJpYyBrZXkgY3J5cHRvZ3JhcGh5KSBh bmQgc2VjcmV0IGtleSAoZm9yIHN5bW1ldHJpYyBrZXkgY3J5cHRvZ3JhcGh5KSB0byBhIHJlY2lw aWVudC4gVGhpcyBwcm9wZXJ0eSBpcyBhbHNvIHNvbWV0aW1lcyBkZXNjcmliZWQgYXMgdGhlIHBy ZXNlbnRlciBiZWluZyBhIGhvbGRlci1vZi1rZXkuDQoNCiogUmVjaXBpZW50OiBQYXJ0eSB0aGF0 IHJlY2VpdmVzIHRoZSBKV1QgdG9nZXRoZXIgd2l0aCB0aGUgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBv ZiB0aGUga2V5ICh0eXBpY2FsbHkgaW4gZm9ybSBvZiBhIGRpZ2l0YWwgc2lnbmF0dXJlIG9yIGEg a2V5ZWQgbWVzc2FnZSBkaWdlc3QpLg0KDQpbSS1ELmlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVy ZV0gZGVzY3JpYmVzIHRoZSB1c2Ugb2YgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBzZW1hbnRpY3MgZm9y IEpTT04gV2ViIFRva2VucyAoSldUcykgZm9yIHRoZSB1c2Ugd2l0aCBPQXV0aC4NCg0KICAgRW52 aXNpb24gdGhlIGZvbGxvd2luZyB0d28gdXNlIGNhc2VzLiBUaGUgZmlyc3QgdXNlIGNhc2UgZGVz Y3JpYmVzDQogICB0aGUgdXNlIG9mIGEgc3ltbWV0cmljIGtleSBhbmQgdGhlIHNlY29uZCB1c2Ug Y2FzZSBmb2N1c2VzIG9uDQogICBhc3ltbWV0cmljIGNyeXB0b2dyYXBoeS4NCg0KICAgQW4gT0F1 dGggMi4wIGF1dGhvcml6YXRpb24gc2VydmVyIGdlbmVyYXRlcyBhIEpXVA0KICAgYW5kIHBsYWNl cyBhbiBlbmNyeXB0ZWQgc3ltbWV0cmljIGtleSBpbnNpZGUgdGhlIG5ld2x5IGludHJvZHVjZWQN CiAgIGNvbmZpcm1hdGlvbiBjbGFpbS4gIFRoaXMgc3ltbWV0cmljIGtleSBpcyBlbmNyeXB0ZWQg d2l0aCBhIGtleSBrbm93bg0KICAgb25seSB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5k IHRoZSByZWNpcGllbnQuIFRoZSBlbnRpcmUgSldUDQogICBpcyB0aGVuIGludGVncml0eSBwcm90 ZWN0ZWQuICBUaGUgSldUIGlzIHRoZW4gc2VudCB0byB0aGUNCiAgIHByZXNlbnRlci4gIFNpbmNl IHRoZSBwcmVzZW50ZXIgaXMgdW5hYmxlIHRvIG9idGFpbiB0aGUNCiAgIGVuY3J5cHRlZCBzeW1t ZXRyaWMga2V5IGZyb20gdGhlIEpXVCBpdHNlbGYsIHRoZSBhdXRob3JpemF0aW9uDQogICBzZXJ2 ZXIgY29udmV5cyB0aGF0IHN5bW1ldHJpYyBrZXkgc2VwYXJhdGVseSB0byB0aGUgcHJlc2VudGVy LiAgTm93LA0KICAgdGhlIHByZXNlbnRlciBpcyBpbiBwb3NzZXNzaW9uIG9mIHRoZSBzeW1tZXRy aWMga2V5IGFzIHdlbGwgYXMgdGhlDQogICBKV1QgKHdoaWNoIGluY2x1ZGVzIHRoZSBjb25maXJt YXRpb24gY2xhaW0gbWVtYmVyKS4gIFdoZW4gdGhlDQogICBwcmVzZW50ZXIgbmVlZHMgdG8gcHJl c2VudCB0aGUgSldUIHRvIHRoZSByZWNpcGllbnQsIGl0IGFsc28gbmVlZHMNCiAgIHRvIGRlbW9u c3RyYXRlIHBvc3Nlc3Npb24gb2YgdGhlIHN5bW1ldHJpYyBrZXk7IHRoZSBwcmVzZW50ZXIsIGZv cg0KICAgZXhhbXBsZSwgdXNlcyB0aGUgc3ltbWV0cmljIGtleSBpbiBhIGNoYWxsZW5nZS9yZXNw b25zZSBwcm90b2NvbA0KICAgd2l0aCB0aGUgcmVjaXBpZW50LiAgVGhlIHJlY2lwaWVudCBpcyBh YmxlIHRvIHZlcmlmeSB0aGF0IGl0IGlzDQogICBpbnRlcmFjdGluZyB3aXRoIHRoZSBnZW51aW5l IHByZXNlbnRlciBieSBkZWNyeXB0aW5nIHRoZSBKV0sNCiAgIGNvbnRhaW5lZCBpbnNpZGUgdGhl IGNvbmZpcm1hdGlvbiBjbGFpbSBvZiB0aGUgSldULiAgQnkgZG9pbmcgdGhpcw0KICAgdGhlIHJl Y2lwaWVudCBvYnRhaW5zIHRoZSBzeW1tZXRyaWMga2V5LCB3aGljaCBpdCB0aGVuIHVzZXMgdG8N CiAgIHZlcmlmeSBjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0ZWQgbWVzc2FnZXMgZXhjaGFuZ2Vk IHdpdGggdGhlDQogICBwcmVzZW50ZXIuDQoNCiAgIFRoaXMgc3ltbWV0cmljIGtleSBtZWNoYW5p c20gZGVzY3JpYmVkIGFib3ZlIGlzIGNvbmNlcHR1YWxseSBzaW1pbGFyDQogICB0byB0aGUgdXNl IG9mIEtlcmJlcm9zIHRpY2tldHMuDQoNCiAgIEluIHRoZSBzZWNvbmQgY2FzZSBjb25zaWRlciBh IHByZXNlbnRlciB0aGF0IGdlbmVyYXRlcyBhIHB1YmxpYyAvDQogICBwcml2YXRlIGtleSBwYWly LiBJdCB0aGVuIHNlbmRzIHRoZSBwdWJsaWMga2V5IHRvIGFuIE9BdXRoIDIuMA0KICAgYXV0aG9y aXphdGlvbiBzZXJ2ZXIsIHdoaWNoIGNyZWF0ZXMgYSBKV1QgYW5kIHBsYWNlcyBhbiBwdWJsaWMg a2V5DQogICAob3IgYSBmaW5nZXJwcmludCBvZiBpdCkgaW5zaWRlIHRoZSBuZXdseSBpbnRyb2R1 Y2VkIGNvbmZpcm1hdGlvbg0KICAgY2xhaW0uIFRoZSBlbnRpcmUgSldUIGlzIHRoZW4gaW50ZWdy aXR5IHByb3RlY3RlZCB1c2luZyBhIGRpZ2l0YWwNCiAgIHNpZ25hdHVyZSB0byBwcm90ZWN0IGl0 IGFnYWluc3QgbW9kaWZpY2F0aW9ucy4NCg0KICAgVGhlIEpXVCBpcyB0aGVuIHNlbnQgdG8gdGhl IHByZXNlbnRlci4gV2hlbiB0aGUgcHJlc2VudGVyIG5lZWRzIHRvDQogICBwcmVzZW50IHRoZSBK V1QgdG8gdGhlIHJlY2lwaWVudCwgaXQgYWxzbyBuZWVkcyB0byBkZW1vbnN0cmF0ZQ0KICAgcG9z c2Vzc2lvbiBvZiB0aGUgcHJpdmF0ZSBrZXkuIFRoZSBwcmVzZW50ZXIsIGZvciBleGFtcGxlLCB1 c2VzIHRoZQ0KICAgcHJpdmF0ZSBrZXkgaW4gVExTIGV4Y2hhbmdlIHdpdGggdGhlIHJlY2lwaWVu dC4gIFRoZSByZWNpcGllbnQNCiAgIGlzIGFibGUgdG8gdmVyaWZ5IHRoYXQgaXQgaXMgaW50ZXJh Y3Rpbmcgd2l0aCB0aGUgZ2VudWluZSBwcmVzZW50ZXINCiAgIGJ5IGV4dHJhY3RpbmcgdGhlIHB1 YmxpYyBrZXkgZnJvbSB0aGUgY29uZmlybWF0aW9uIGNsYWltIG9mIHRoZQ0KICAgSldUIChhZnRl ciB2ZXJpZnlpbmcgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlIG9mIHRoZSBKV1QpIGFuZCB1dGlsaXpp bmcNCiAgIGl0IHdpdGggdGhlIHByaXZhdGUga2V5IGluIHRoZSBUTFMgZXhjaGFuZ2UuDQoNCiAg IFRoZSBhc3ltbWV0cmljIGtleSBtZWNoYW5pc20gZGVzY3JpYmVkIGFib3ZlIGlzIGNvbmNlcHR1 YWxseSBzaW1pbGFyDQogICB0byBhIGNlcnRpZmljYXRlLg0KDQogICBJbiBib3RoIGNhc2VzIHRo ZSBKV1QgbWF5IGNvbnRhaW4gdmFyaW91cyBjbGFpbXMgdGhhdCBhcmUgaW5jbHVkZWQNCiAgIGJh c2VkIG9uIHRoZSBwb2xpY3kgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0KDQotLS0tDQoN CkR1ZSB0byB0aGUgSUVURiBkcmFmdCBzdWJtaXNzaW9uIGRlYWRsaW5lIHdlIHdvdWxkIGFwcHJl Y2lhdGUgYSByZXNwb25zZSBieSBuZXh0IFN1bmRheS4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KDQoN Cg== From nobody Wed Mar 4 15:30:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ECE1A0067 for ; Wed, 4 Mar 2015 15:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mRB9pbVWuzUL for ; Wed, 4 Mar 2015 15:30:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6221A0064 for ; Wed, 4 Mar 2015 15:30:40 -0800 (PST) Received: from BN1PR0301MB0641.namprd03.prod.outlook.com (25.160.171.14) by BN1PR0301MB0643.namprd03.prod.outlook.com (25.160.171.16) with Microsoft SMTP Server (TLS) id 15.1.99.9; Wed, 4 Mar 2015 23:28:48 +0000 Received: from CH1PR03CA010.namprd03.prod.outlook.com (10.255.156.155) by BN1PR0301MB0641.namprd03.prod.outlook.com (25.160.171.14) with Microsoft SMTP Server (TLS) id 15.1.99.9; Wed, 4 Mar 2015 23:28:47 +0000 Received: from BL2FFO11FD019.protection.gbl (10.255.156.132) by CH1PR03CA010.outlook.office365.com (10.255.156.155) with Microsoft SMTP Server (TLS) id 15.1.99.14 via Frontend Transport; Wed, 4 Mar 2015 23:28:46 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD019.mail.protection.outlook.com (10.173.161.37) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 4 Mar 2015 23:28:46 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.74]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0224.003; Wed, 4 Mar 2015 23:28:19 +0000 From: Mike Jones To: Justin Richer , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" Thread-Index: AQHQVaC54CohmDLCbEuXvzRHTtpjuJ0M3fEAgAAJBZA= Date: Wed, 4 Mar 2015 23:28:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> In-Reply-To: <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2E78D9FTK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; MIT.EDU; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(438002)(24454002)(189002)(15584002)(51914003)(53754006)(377454003)(199003)(19300405004)(19580405001)(2171001)(2656002)(87936001)(19617315012)(84326002)(104016003)(19580395003)(6806004)(16236675004)(86362001)(19625215002)(86612001)(33656002)(15395725005)(50986999)(76176999)(66066001)(54356999)(46102003)(512874002)(77156002)(62966003)(15975445007)(85806002)(106116001)(2900100001)(2920100001)(2950100001)(92566002)(106466001)(102836002)(55846006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0641; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0641; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0643; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BN1PR0301MB0641; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0641; X-Forefront-PRVS: 0505147DDB X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2015 23:28:46.1497 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0641 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 23:30:45 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943A2E78D9FTK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHNldmVyZSBjb25jZXJucyB3aXRoIHRoaXMgYXBwcm9hY2guICBJdOKAmXMgbm90IGFw cHJvcHJpYXRlIHRvIHJlZ2lzdGVyIGFyYml0cmFyeSBKU09OIG9iamVjdCBtZW1iZXIgbmFtZXMg YXMgSldUIGNsYWltIG5hbWVzIOKAkyBlc3BlY2lhbGx5IHdoZW4gdGhlIEpTT04gb2JqZWN0IG1l bWJlciBuYW1lcyBhcmUgbm90IGV2ZW4gYmVpbmcgdXNlZCBhcyBKV1QgY2xhaW0gbmFtZXMuICBQ bGVhc2UgZG8gbm90IGRvIHRoaXMsIGFzIGl0IHdvdWxkIG5lZWRsZXNzbHkgcG9sbHV0ZSB0aGUg SldUIGNsYWltIG5hbWUgbmFtZXNwYWNlIHdpdGggcmVnaXN0ZXJlZCBuYW1lcyB0aGF0IGFyZSBh cHBsaWNhdGlvbiBzcGVjaWZpYy4NCg0KU2Vjb25kYXJpbHksIEkgaGF2ZSBjb25jZXJucyBhYm91 dCB0aGVzZSBuYW1lcyBhbmQgc3VnZ2VzdGlvbnMgZm9yIGhvdyB0byBhZGRyZXNzIHRoZW0uDQoN CuKAnGFjdGl2ZeKAnSDigJMgVGhpcyBjbGFpbSBpcyBub3QgcHJlc2VudGx5IGFkZXF1YXRlbHkg ZGVmaW5lZC4gIEFuZCBpdHMgZGVmaW5pdGlvbiB3aWxsIG9mIG5lY2Vzc2l0eSBiZSBzcGVjaWZp YyB0byB0aGUgaW50cm9zcGVjdGlvbiBhcHBsaWNhdGlvbi4gIFRoZXJlZm9yZSwgaXQgc2hvdWxk IG5vdCBiZSByZWdpc3RlcmVkIGFzIGEgZ2VuZXJhbCBKV1QgY2xhaW0gbmFtZS4gIEEgbmFtZSBJ IHdvdWxkIGJlIGNvbWZvcnRhYmxlIHdpdGggZm9yIHRoaXMgY29uY2VwdCB3b3VsZCBiZSB1cm46 aWV0ZjpwYXJhbXM6b2F1dGg6aW50cm9zcGVjdGlvbjphY3RpdmUsIHNpbmNlIGl0IG1ha2VzIGl0 IGNsZWFyIHdoYXQgYXBwbGljYXRpb24gdGhlIG5hbWUgaXMgdXNlZCB3aXRoLg0KDQrigJx1c2Vy X2lk4oCdIOKAkyBUaGUgY29uY2VwdCB5b3XigJlyZSBkZXNjcmliaW5nIGlzIGFsbW9zdCB1bml2 ZXJzYWxseSBjYWxsZWQg4oCcdXNlcm5hbWXigJ0uICBVc2VyIElEIGlzIHR5cGljYWxseSB0aGUg bnVtZXJpYyBhY2NvdW50IGlkZW50aWZpZXIgKGNhcnJpZWQgaW4gdGhlIOKAnHN1YuKAnSBjbGFp bSBpbiBhIEpXVCksIGFuZCBzbyBpcyBub3QgdGhlIHJpZ2h0IG5hbWUgZm9yIHRoaXMuICBDb21w YXJlIGl0IHRvIHRoZSBwcmVmZXJyZWRfdXNlcm5hbWUgY2xhaW0gaW4gT3BlbklEIENvbm5lY3Qu ICBQbGVhc2UgY2hhbmdlIHRoaXMgZWl0aGVyIHRvIOKAnHVzZXJuYW1l4oCdIG9yIHVybjppZXRm OnBhcmFtczpvYXV0aDppbnRyb3NwZWN0aW9uOnVzZXJuYW1lLg0KDQrigJx0b2tlbl90eXBl4oCd IOKAkyBXaGlsZSB0aGlzIGlzIHdlbGwtZGVmaW5lZCwgdGhlIHVzYWdlIGlzIGZhaXJseSBzcGVj aWZpYyB0byB0aGlzIGFwcGxpY2F0aW9uLiAgQWdhaW4sIGFkZGluZyB0aGUgdXJuOmlldGY6cGFy YW1zOm9hdXRoOmludHJvc3BlY3Rpb246IG5hbWUgcHJlZml4IHdvdWxkIGFkZHJlc3MgdGhpcyBp c3N1ZS4NCg0KSWYgeW91IGdpdmUgdXAgcmVnaXN0ZXJpbmcgdGhlc2UgbmFtZXMgaW4gdGhlIEpX VCBDbGFpbXMgcmVnaXN0cnksIEnigJltIE9LIHdpdGggeW91IHVzaW5nIHNob3J0IG5hbWVzLiAg QnV0IGlmIHlvdSB3YW50IHRoZW0gdG8gbGl2ZSBhbG9uZ3NpZGUgb3RoZXIgSldUIGNsYWltIG5h bWVzLCBwbGVhc2UgaW5jbHVkZSB0aGUgdXJuOmlldGY6cGFyYW1zOm9hdXRoOmludHJvc3BlY3Rp b246IGluIGxpZXUgb2YgcmVnaXN0cmF0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFuayB5b3UsDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDQsIDIwMTUgMTo0NiBQ TQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gQWxpZ25tZW50IG9mIEpXVCBDbGFpbXMgYW5kIFRva2VuIEludHJvc3Bl Y3Rpb24gIkNsYWltcyINCg0KSGkgSGFubmVzLCB0aGFua3MgZm9yIHRoZSBmZWVkYmFjay4gUmVz cG9uc2VzIGlubGluZS4NCg0KT24gTWFyIDMsIDIwMTUsIGF0IDU6NTYgQU0sIEhhbm5lcyBUc2No b2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0Pj4gd3JvdGU6DQoNCkhpIEp1c3RpbiwgSGkgYWxsLA0KDQppbiBPQXV0aCB3ZSBw cm92aWRlIHR3byB3YXlzIGZvciBhIHJlc291cmNlIHNlcnZlciB0byBtYWtlIGFuDQphdXRob3Jp emF0aW9uIGRlY2lzaW9uLg0KDQoxKSBUaGUgcmVzb3VyY2Ugc2VydmVyIHJlY2VpdmVzIGEgc2Vs Zi1jb250YWluZWQgdG9rZW4gdGhhdCBjb250YWlucyBhbGwNCnRoZSBuZWNlc3NhcnkgaW5mb3Jt YXRpb24gdG8gbWFrZSBhIGxvY2FsIGF1dGhvcml6YXRpb24gZGVjaXNpb24uIFdpdGgNCnRoZSBK V1Qgd2UgaGF2ZSBjcmVhdGVkIHN1Y2ggYSBzdGFuZGFyZGl6ZWQgaW5mb3JtYXRpb24gYW5kIGRh dGEgbW9kZWwuDQoNCjIpIFdpdGggYW4gYWNjZXNzIHJlcXVlc3QgZnJvbSBhIGNsaWVudCB0aGUg cmVzb3VyY2Ugc2VydmVyIGFza3MgdGhlDQphdXRob3JpemF0aW9uIHNlcnZlciBmb3IgImhlbHAi LiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcHJvdmlkZXMNCmluZm9ybWF0aW9uIHRoYXQgaGVs cCBtYWtlIHRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9uLiBUaGlzIGlzIHRoZSB0b2tlbg0KaW50 cm9zcGVjdGlvbiBhcHByb2FjaC4NCg0KSSBiZWxpZXZlIHRoZSB0d28gYXBwcm9hY2hlcyBuZWVk IHRvIGJlIGFsaWduZWQgd2l0aCByZWdhcmQgdG8gdGhlDQppbmZvcm1hdGlvbiBhbmQgdGhlIGRh dGEgbW9kZWwuIFNpbmNlIGJvdGggZG9jdW1lbnRzIGFscmVhZHkgdXNlIEpTT04gYXMNCmEgd2F5 IHRvIGVuY29kZSBpbmZvcm1hdGlvbiAoPWRhdGEgbW9kZWwpIGFuZCBhbG1vc3QgaGF2ZSBhbiBp ZGVudGljYWwNCmluZm9ybWF0aW9uIG1vZGVsICh0aGUgZGF0YSB0aGF0IGlzIGJlaW5nIHBhc3Nl ZCBhcm91bmQpLg0KDQpXaGF0IG5lZWRzIHRvIGJlIGRvbmU/DQoNCiogVXNlIHRoZSB0ZXJtICdj bGFpbXMnIGluIGJvdGggZG9jdW1lbnRzLg0KKiBVc2UgdGhlIHNhbWUgcmVnaXN0cnkgKGkuZS4s IHRoZSByZWdpc3RyeSBlc3RhYmxpc2hlZCB3aXRoIHRoZSBKV1QpLg0KKiBSZWdpc3RlciB0aGUg bmV3bHkgZGVmaW5lZCBjbGFpbXMgZnJvbSB0aGUgdG9rZW4gaW50cm9zcGVjdGlvbg0KZG9jdW1l bnQgaW4gdGhlIGNsYWltcyByZWdpc3RyeS4NCg0KV2XigJl2ZSBhbHJlYWR5IGRvbmUgdGhpcyBp biB0aGUgbGF0ZXN0IGRyYWZ0LiBPciBhdCBsZWFzdCwgdGhhdOKAmXMgdGhlIGludGVudCBvZiB0 aGUgY3VycmVudCB0ZXh0IOKAlCB0aGUgcmVnaXN0cnkgaXMgcmVmZXJlbmNlZCBhbmQgdGhlIG5l dyBjbGFpbXMgYXJlIHJlZ2lzdGVyZWQuIENhbiB5b3Ugc3BlY2lmaWNhbGx5IHBvaW50IHRvIHBs YWNlcyB3aGVyZSB0aGlzIG5lZWRzIHRvIGJlIGltcHJvdmVkIHVwb24/DQoNCg0KVGhlbiwgSSBo YXZlIGEgZmV3IGNvbW1lbnRzIG9uIHRoZSBuZXcgY2xhaW1zIHRoYXQgYXJlIHByb3Bvc2VkOg0K DQpIZXJlIGlzIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAnYWN0aXZlJyBjbGFpbToNCg0KICBhY3Rp dmUNCiAgICAgUkVRVUlSRUQuICBCb29sZWFuIGluZGljYXRvciBvZiB3aGV0aGVyIG9yIG5vdCB0 aGUgcHJlc2VudGVkIHRva2VuDQogICAgIGlzIGN1cnJlbnRseSBhY3RpdmUuICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgZGV0ZXJtaW5lcyB3aGV0aGVyDQogICAgIGFuZCB3aGVuIGEgZ2l2ZW4g dG9rZW4gaXMgaW4gYW4gYWN0aXZlIHN0YXRlLg0KDQpUaGlzIGNsYWltIGlzIG5vdCB3ZWxsLWRl ZmluZWQuIFlvdSBuZWVkIHRvIGV4cGxhaW4gd2hhdCAiYWN0aXZlIiBtZWFucy4NCkl0IGNvdWxk LCBmb3IgZXhhbXBsZSwgbWVhbiB0aGF0IHRoZSB0b2tlbiBpcyBub3QgeWV0IGV4cGlyZWQuIFRo ZW4sDQp0aGVyZSBpcyBvZiBjb3Vyc2UgdGhlIHF1ZXN0aW9uIHdoeSB5b3UgYXJlIG5vdCByZXR1 cm5pbmcgdGhlICdleHAnDQpjbGFpbSB0b2dldGhlciB3aXRoIHRoZSAnbmJmJyBjbGFpbS4NCg0K VGhlIGRlZmluaXRpb24gb2Yg4oCcYWN0aXZl4oCdIGlzIHJlYWxseSB1cCB0byB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIsIGFuZCBJ4oCZdmUgeWV0IHRvIGhlYXIgZnJvbSBhbiBhY3R1YWwgaW1w bGVtZW50b3Igd2hv4oCZcyBjb25mdXNlZCBieSB0aGlzIGRlZmluaXRpb24uIFdoZW4geW914oCZ cmUgdGhlIG9uZSBpc3N1aW5nIHRoZSB0b2tlbnMsIHlvdSBrbm93IHdoYXQgYW4g4oCcYWN0aXZl 4oCdIHRva2VuIG1lYW5zIHRvIHlvdS4gU3RpbGwsIHBlcmhhcHMgd2UgY2FuIGJlIGV2ZW4gbW9y ZSBleHBsaWNpdCwgc3VjaCBhczoNCg0KDQphY3RpdmUNCiAgUkVRVUlSRUQuIEJvb2xlYW4gaW5k aWNhdG9yIG9mIHdoZXRoZXIgb3Igbm90IHRoZSBwcmVzZW50ZWQgdG9rZW4gaXMgY3VycmVudGx5 IGFjdGl2ZS4gVGhlIHNwZWNpZmljcyBvZiBhIHRva2Vu4oCZcyBhY3RpdmUgc3RhdGUgd2lsbCB2 YXJ5IGRlcGVuZGluZyBvbiB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyLCBidXQgZ2VuZXJhbGx5IHRoaXMgd2lsbCBpbmRpY2F0ZSB0aGF0IGEgZ2l2ZW4gdG9r ZW4gaGFzIGJlZW4gaXNzdWVkIGJ5IHRoaXMgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGhhcyBub3Qg YmVlbiByZXZva2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lciwgYW5kIGlzIHdpdGhpbiBpdHMgZ2l2 ZW4gdGltZSB3aW5kb3cgb2YgdmFsaWRpdHkgKGUuZy4gbm90IGV4cGlyZWQpLg0KDQpBbHNvLCB0 aGlzIGlzIG9uZSBvZiB0aGUgcGxhY2VzIHdoZXJlIHRoZSBvdmVybGFwIGJldHdlZW4gSldUIGFu ZCBpbnRyb3NwZWN0aW9uIGNsYWltcyBkb27igJl0IG1ha2Ugc2Vuc2UuIEl0IGRvZXNu4oCZdCBt YWtlIGFueSBzZW5zZSBmb3IgYSBKV1QgdG8gY2FycnkgYW4g4oCcYWN0aXZl4oCdIGNsYWltIGF0 IGFsbC4gV2h5IHdvdWxkIHlvdSBoYXZlIGEgSldUIGNsYWltIHRvIGJlIGFueXRoaW5nIGJ1dCBh Y3RpdmU/IFdlIHNob3VsZCByZWdpc3RlciBpdCB3aXRoIHRoZSBKV1QgcmVnaXN0cnkgdG8gYXZv aWQgbmFtZSBjb2xsaXNpb25zLCBidXQgdGhlcmXigJlzIG5vdGhpbmcgaW4gdGhlIEpXVCByZWdp c3RyeSB0aGF0IHNheXMg4oCcZG9u4oCZdCB1c2UgdGhpcyBpbnNpZGUgb2YgYSBKV1TigJ0uIERv IHlvdSBoYXZlIGFueSBhZHZpY2Ugb24gaG93IHRvIGFkZHJlc3MgdGhpcz8NCg0KDQoNCmNsaWVu dF9pZDogV2hhdCBpcyB0aGUgcmVzb3VyY2Ugc2VydmVyIGdvaW5nIHRvIGRvIHdpdGggdGhlIGNs aWVudF9pZD8NCldoYXQgYXV0aG9yaXphdGlvbiBkZWNpc2lvbiBjb3VsZCBpdCBtYWtlPw0KDQpX aGF0ZXZlciBpdCB3YW50cyB0by4gSWYgYW4gUlMgY2FuIGZpZ3VyZSBvdXQgc29tZXRoaW5nIGZy b20gdGhlIGNsaWVudF9pZCwgd2h5IG5vdCBsZXQgaXQ/IFRoZSBjbGllbnRfaWQgaXMgYSBwaWVj ZSBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWFuY2Ugb2YgdGhl IHRva2VuLCBhbmQgYSBjb21tb24gZW5vdWdoIE9BdXRoIHZhbHVlIGZvciBkZWNpc2lvbiBtYWtp bmcuDQoNCg0KSSBoYXZlIGEgY291cGxlIG9mIHJlYWN0aW9ucyB3aGVuIEkgcmVhZCB0aGUgJ3Vz ZXJfaWQnIGNsYWltOg0KIC0gSSBiZWxpZXZlIHRoZSBpbmNsdXNpb24gb2YgYSB1c2VyIGlkIGZp ZWxkIGluIHRoZSByZXNwb25zZSBjb3VsZA0KbGVhZCB0byBmdXJ0aGVyIGNvbmZ1c2lvbiByZWdh cmRpbmcgT0F1dGggYWNjZXNzIHRva2VuIHVzYWdlIGZvcg0KYXV0aGVudGljYXRpb24uDQoNClRo aXMgaXNu4oCZdCBhbnkgZGlmZmVyZW50IGZyb20gaGF2aW5nIGEgdXNlcmluZm8tZW5kcG9pbnQg ZXF1aXZhbGVudCAobGlrZSBzb2NpYWwgZ3JhcGggb3IgdHdpdHRlciBBUEkpIGFuZCBpdOKAmXMg Z290IHRoZSBzYW1lIHRyb3VibGUuDQoNCg0KDQogLSBTaW5jZSB5b3UgZGVmaW5lIGl0IGFzIGEg aHVtYW4gcmVhZGFibGUgaWRlbnRpZmllciBJIGFtIHdvbmRlcmluZw0Kd2hldGhlciB5b3Ugd2Fu dCB0byBzYXkgc29tZXRoaW5nIGFib3V0IHRoZSB1c2FnZS4gSGVyZSBpdCBzZWVtcyB0aGF0IGl0 DQptaWdodCBiZSB1c2VkIGZvciBkaXNwbGF5aW5nIHNvbWV0aGluZyBvbiBhIHdlYnBhZ2UgcmF0 aGVyIHRoYW4gbWFraW5nDQphbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGJ1dCBJIG1pZ2h0IHdl bGwgYmUgd3JvbmcuDQoNCldlIGFkZGVkIGluIOKAnHVzZXJfaWTigJ0gdG8gb3VyIGltcGxlbWVu dGF0aW9uIGR1ZSB0byBkZXZlbG9wZXIgZGVtYW5kIOKAlCB0aGV5IHdhbnRlZCBhIHVzZXJuYW1l IGFzc29jaWF0ZWQgd2l0aCB0aGUgcmV0dXJuIHZhbHVlLCBidXQgdG8gbGVhdmUgdGhlIOKAnHN1 YuKAnSB2YWx1ZSB0aGUgc2FtZSBhcyB0aGF0IGRlZmluZWQgYnkgT3BlbklEIENvbm5lY3QuIE5v dGUgdGhhdCB0aGlzIGlzIGluIGFuIGVudmlyb25tZW50IHdoZXJlIHRoZSB1c2VybmFtZSBpcyBh IGtub3duIHF1YW50aXR5LCBhbmQgdGhleeKAmXJlIG5vdCB0cnlpbmcgdG8gZG8gY3Jvc3MtZG9t YWluIGF1dGhlbnRpY2F0aW9uLiBUaGV5IGp1c3Qgd2FudCB0byBrbm93IHdob3NlIHRva2VuIHRo aXMgd2FzIHNvIHRoZXkgY2FuIGZpZ3VyZSBvdXQgd2hvc2UgZGF0YSB0byByZXR1cm4uIEl04oCZ cyBub3QgdXNlZCBmb3IgZGlzcGxheSwgYnV0IEkgdHJpZWQgdG8gbWFrZSB0aGUgZGVmaW5pdGlv biBpbiBjb250cmFzdCB0byB0aGUgbWFjaGluZS1mYWNpbmcg4oCcc3Vi4oCdIHZhbHVlLg0KDQoN Cg0KIC0gSSBhbSBtaXNzaW5nIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgcHJpdmFjeSBpbXBsaWNh dGlvbnMgb2YgaXQuDQpXaGlsZSB0aGVyZSBpcyBhIHByaXZhY3kgY29uc2lkZXJhdGlvbiBzZWN0 aW9uIEkgYW0gd29uZGVyaW5nIHdoYXQNCmNvbnRyb2xzIHRoZSByZWxlYXNlIG9mIHRoaXMgc2Vu c2l0aXZlIGluZm9ybWF0aW9uIGZyb20gdGhlDQphdXRob3JpemF0aW9uIHNlcnZlciB0byB0aGUg cmVzb3VyY2Ugc2VydmVyLiBXaGlsZSBpbiBzb21lIGNhc2VzIHRoZSB0d28NCnBhcnRpZXMgbWln aHQgYmVsb25nIHRvIHRoZSBzYW1lIG9yZ2FuaXphdGlvbiBidXQgaW4gb3RoZXIgY2FzZXMgdGhh dA0KbWF5IG5vdCBuZWNlc3NhcmlseSBiZSB0cnVlLg0KDQpZb3XigJlyZSBjb3JyZWN0LCB0aGlz IGlzIGN1cnJlbnRseSBtaXNzaW5nIGFuZCBJ4oCZbGwgYWRkIHRoYXQgaW4uDQoNCg0KDQogLSBJ biB0ZXJtcyBvZiB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGFib3V0IHRoZSB1c2VyIEkgYW0g Y3VyaW91cw0KYWJvdXQgdGhlIHVzZWZ1bG5lc3Mgb2YgaW5jbHVkaW5nIG90aGVyIGluZm9ybWF0 aW9uIGFzIHdlbGwsIHN1Y2ggYXMgdGhlDQppbmZvIHRoYXQgaXMgaW5jbHVkZWQgaW4gYW4gaWQg dG9rZW4gKHNlZQ0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0x XzAuaHRtbCNJRFRva2VuKS4gSWYgdGhpcw0KaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgSUQg dG9rZW4gY29uY2VwdCBhbmQgdGhlIGluZm9ybWF0aW9uIGNhcnJpZWQNCndpdGhpbiBpdCB0aGVu IEkgd291bGQgYWRkIHRoYXQgcmVtYXJrLg0KDQoNCllvdSBjb3VsZCBpbnRyb3NwZWN0IGFuIElE IHRva2VuIGlmIHlvdSB3YW50ZWQgdG8sIGJ1dCBpdOKAmXMgdXN1YWxseSBlYXNpZXIgdG8ganVz dCBwYXJzZSBpdCB5b3Vyc2VsZiBiZWNhdXNlIGl04oCZcyBzZWxmLWNvbnRhaW5lZC4gVGhlIElE IFRva2VuIGFsc28gZXh0ZW5kcyBKV1QsIHNvIHRoZXJl4oCZcyBub3RoaW5nIHN0b3BwaW5nIHlv dSBmcm9tIHJldHVybmluZyB0aG9zZSBjbGFpbXMgYXMgd2VsbC4gSG93ZXZlciwgbm90ZSB0aGF0 IHRoZSBhdWRpZW5jZSBvZiB0aGUgSUQgdG9rZW4gaXMgdGhlIE9BdXRoICpjbGllbnQqIHdoZXJl YXMgdGhlIHRhcmdldGVkIHVzZXIgb2YgdGhlIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgaXMgdGhl ICpwcm90ZWN0ZWQgcmVzb3VyY2UqLiBUaGUgUFIgaXNu4oCZdCBnb2luZyB0byBzZWUgdGhlIElE IFRva2VuIG1vc3Qgb2YgdGhlIHRpbWUsIGFuZCB0aGUgY2xpZW504oCZcyBub3QgZ29pbmcgdG8g bmVlZCB0byAob3IgYmUgYWJsZSB0bykgaW50cm9zcGVjdCBpdHMgdG9rZW5zIG1vc3Qgb2YgdGhl IHRpbWUsIHNvIGluIHByYWN0aWNlIHRoZXJl4oCZcyBub3QgcmVhbGx5IGFueSBvdmVybGFwLg0K DQog4oCUIEp1c3Rpbg0KDQoNCg0KQ2lhbw0KSGFubmVzDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_4E1F6AAD24975D4BA5B1680429673943A2E78D9FTK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIHNldmVyZSBjb25jZXJucyB3aXRoIHRoaXMg YXBwcm9hY2guJm5ic3A7IEl04oCZcyBub3QgYXBwcm9wcmlhdGUgdG8gcmVnaXN0ZXIgYXJiaXRy YXJ5IEpTT04gb2JqZWN0IG1lbWJlciBuYW1lcyBhcyBKV1QgY2xhaW0gbmFtZXMg4oCTIGVzcGVj aWFsbHkgd2hlbiB0aGUgSlNPTg0KIG9iamVjdCBtZW1iZXIgbmFtZXMgYXJlIG5vdCBldmVuIGJl aW5nIHVzZWQgYXMgSldUIGNsYWltIG5hbWVzLiZuYnNwOyA8Yj5QbGVhc2UgZG8gbm90IGRvIHRo aXM8L2I+LCBhcyBpdCB3b3VsZCBuZWVkbGVzc2x5IHBvbGx1dGUgdGhlIEpXVCBjbGFpbSBuYW1l IG5hbWVzcGFjZSB3aXRoIHJlZ2lzdGVyZWQgbmFtZXMgdGhhdCBhcmUgYXBwbGljYXRpb24gc3Bl Y2lmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TZWNvbmRhcmlseSwgSSBoYXZlIGNvbmNlcm5zIGFib3V0IHRoZXNl IG5hbWVzIGFuZCBzdWdnZXN0aW9ucyBmb3IgaG93IHRvIGFkZHJlc3MgdGhlbS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PuKAnGFjdGl2ZeKAnSDigJMgVGhpcyBjbGFpbSBpcyBub3QgcHJlc2VudGx5IGFkZXF1YXRlbHkg ZGVmaW5lZC4mbmJzcDsgQW5kIGl0cyBkZWZpbml0aW9uIHdpbGwgb2YgbmVjZXNzaXR5IGJlIHNw ZWNpZmljIHRvIHRoZSBpbnRyb3NwZWN0aW9uIGFwcGxpY2F0aW9uLiZuYnNwOyBUaGVyZWZvcmUs IGl0DQogc2hvdWxkIG5vdCBiZSByZWdpc3RlcmVkIGFzIGEgZ2VuZXJhbCBKV1QgY2xhaW0gbmFt ZS4mbmJzcDsgQSBuYW1lIEkgd291bGQgYmUgY29tZm9ydGFibGUgd2l0aCBmb3IgdGhpcyBjb25j ZXB0IHdvdWxkIGJlIHVybjppZXRmOnBhcmFtczpvYXV0aDppbnRyb3NwZWN0aW9uOmFjdGl2ZSwg c2luY2UgaXQgbWFrZXMgaXQgY2xlYXIgd2hhdCBhcHBsaWNhdGlvbiB0aGUgbmFtZSBpcyB1c2Vk IHdpdGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj7igJx1c2VyX2lk4oCdIOKAkyBUaGUgY29uY2VwdCB5b3XigJlyZSBk ZXNjcmliaW5nIGlzIGFsbW9zdCB1bml2ZXJzYWxseSBjYWxsZWQg4oCcdXNlcm5hbWXigJ0uJm5i c3A7IFVzZXIgSUQgaXMgdHlwaWNhbGx5IHRoZSBudW1lcmljIGFjY291bnQgaWRlbnRpZmllciAo Y2FycmllZCBpbiB0aGUg4oCcc3Vi4oCdDQogY2xhaW0gaW4gYSBKV1QpLCBhbmQgc28gaXMgbm90 IHRoZSByaWdodCBuYW1lIGZvciB0aGlzLiZuYnNwOyBDb21wYXJlIGl0IHRvIHRoZSBwcmVmZXJy ZWRfdXNlcm5hbWUgY2xhaW0gaW4gT3BlbklEIENvbm5lY3QuJm5ic3A7IFBsZWFzZSBjaGFuZ2Ug dGhpcyBlaXRoZXIgdG8g4oCcdXNlcm5hbWXigJ0gb3IgdXJuOmlldGY6cGFyYW1zOm9hdXRoOmlu dHJvc3BlY3Rpb246dXNlcm5hbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJx0b2tlbl90eXBl4oCdIOKAkyBXaGls ZSB0aGlzIGlzIHdlbGwtZGVmaW5lZCwgdGhlIHVzYWdlIGlzIGZhaXJseSBzcGVjaWZpYyB0byB0 aGlzIGFwcGxpY2F0aW9uLiZuYnNwOyBBZ2FpbiwgYWRkaW5nIHRoZSB1cm46aWV0ZjpwYXJhbXM6 b2F1dGg6aW50cm9zcGVjdGlvbjogbmFtZSBwcmVmaXgNCiB3b3VsZCBhZGRyZXNzIHRoaXMgaXNz dWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JZiB5b3UgZ2l2ZSB1cCByZWdpc3RlcmluZyB0aGVzZSBuYW1lcyBpbiB0 aGUgSldUIENsYWltcyByZWdpc3RyeSwgSeKAmW0gT0sgd2l0aCB5b3UgdXNpbmcgc2hvcnQgbmFt ZXMuJm5ic3A7IEJ1dCBpZiB5b3Ugd2FudCB0aGVtIHRvIGxpdmUgYWxvbmdzaWRlIG90aGVyIEpX VCBjbGFpbQ0KIG5hbWVzLCBwbGVhc2UgaW5jbHVkZSB0aGUgdXJuOmlldGY6cGFyYW1zOm9hdXRo OmludHJvc3BlY3Rpb246IGluIGxpZXUgb2YgcmVnaXN0cmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAwNCwgMjAxNSAxOjQ2IFBNPGJyPg0KPGI+VG86PC9i PiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCjxiPkNjOjwvYj4gJmx0O29hdXRoQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBbGlnbm1lbnQgb2YgSldUIENs YWltcyBhbmQgVG9rZW4gSW50cm9zcGVjdGlvbiAmcXVvdDtDbGFpbXMmcXVvdDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBIYW5uZXMsIHRoYW5rcyBm b3IgdGhlIGZlZWRiYWNrLiBSZXNwb25zZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAzLCAyMDE1LCBhdCA1OjU2IEFNLCBIYW5u ZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5I aSBKdXN0aW4sIEhpIGFsbCw8YnI+DQo8YnI+DQppbiBPQXV0aCB3ZSBwcm92aWRlIHR3byB3YXlz IGZvciBhIHJlc291cmNlIHNlcnZlciB0byBtYWtlIGFuPGJyPg0KYXV0aG9yaXphdGlvbiBkZWNp c2lvbi48YnI+DQo8YnI+DQoxKSBUaGUgcmVzb3VyY2Ugc2VydmVyIHJlY2VpdmVzIGEgc2VsZi1j b250YWluZWQgdG9rZW4gdGhhdCBjb250YWlucyBhbGw8YnI+DQp0aGUgbmVjZXNzYXJ5IGluZm9y bWF0aW9uIHRvIG1ha2UgYSBsb2NhbCBhdXRob3JpemF0aW9uIGRlY2lzaW9uLiBXaXRoPGJyPg0K dGhlIEpXVCB3ZSBoYXZlIGNyZWF0ZWQgc3VjaCBhIHN0YW5kYXJkaXplZCBpbmZvcm1hdGlvbiBh bmQgZGF0YSBtb2RlbC48YnI+DQo8YnI+DQoyKSBXaXRoIGFuIGFjY2VzcyByZXF1ZXN0IGZyb20g YSBjbGllbnQgdGhlIHJlc291cmNlIHNlcnZlciBhc2tzIHRoZTxicj4NCmF1dGhvcml6YXRpb24g c2VydmVyIGZvciAmcXVvdDtoZWxwJnF1b3Q7LiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcHJv dmlkZXM8YnI+DQppbmZvcm1hdGlvbiB0aGF0IGhlbHAgbWFrZSB0aGUgYXV0aG9yaXphdGlvbiBk ZWNpc2lvbi4gVGhpcyBpcyB0aGUgdG9rZW48YnI+DQppbnRyb3NwZWN0aW9uIGFwcHJvYWNoLjxi cj4NCjxicj4NCkkgYmVsaWV2ZSB0aGUgdHdvIGFwcHJvYWNoZXMgbmVlZCB0byBiZSBhbGlnbmVk IHdpdGggcmVnYXJkIHRvIHRoZTxicj4NCmluZm9ybWF0aW9uIGFuZCB0aGUgZGF0YSBtb2RlbC4g U2luY2UgYm90aCBkb2N1bWVudHMgYWxyZWFkeSB1c2UgSlNPTiBhczxicj4NCmEgd2F5IHRvIGVu Y29kZSBpbmZvcm1hdGlvbiAoPWRhdGEgbW9kZWwpIGFuZCBhbG1vc3QgaGF2ZSBhbiBpZGVudGlj YWw8YnI+DQppbmZvcm1hdGlvbiBtb2RlbCAodGhlIGRhdGEgdGhhdCBpcyBiZWluZyBwYXNzZWQg YXJvdW5kKS48YnI+DQo8YnI+DQpXaGF0IG5lZWRzIHRvIGJlIGRvbmU/PGJyPg0KPGJyPg0KKiBV c2UgdGhlIHRlcm0gJ2NsYWltcycgaW4gYm90aCBkb2N1bWVudHMuPGJyPg0KKiBVc2UgdGhlIHNh bWUgcmVnaXN0cnkgKGkuZS4sIHRoZSByZWdpc3RyeSBlc3RhYmxpc2hlZCB3aXRoIHRoZSBKV1Qp Ljxicj4NCiogUmVnaXN0ZXIgdGhlIG5ld2x5IGRlZmluZWQgY2xhaW1zIGZyb20gdGhlIHRva2Vu IGludHJvc3BlY3Rpb248YnI+DQpkb2N1bWVudCBpbiB0aGUgY2xhaW1zIHJlZ2lzdHJ5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XZeKAmXZlIGFscmVhZHkgZG9uZSB0aGlzIGluIHRoZSBsYXRlc3QgZHJhZnQuIE9y IGF0IGxlYXN0LCB0aGF04oCZcyB0aGUgaW50ZW50IG9mIHRoZSBjdXJyZW50IHRleHQg4oCUIHRo ZSByZWdpc3RyeSBpcyByZWZlcmVuY2VkIGFuZCB0aGUgbmV3IGNsYWltcyBhcmUgcmVnaXN0ZXJl ZC4gQ2FuIHlvdSBzcGVjaWZpY2FsbHkgcG9pbnQgdG8gcGxhY2VzIHdoZXJlIHRoaXMgbmVlZHMg dG8gYmUgaW1wcm92ZWQgdXBvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlbiwgSSBoYXZlIGEgZmV3IGNvbW1lbnRzIG9uIHRoZSBuZXcgY2xhaW1zIHRo YXQgYXJlIHByb3Bvc2VkOjxicj4NCjxicj4NCkhlcmUgaXMgdGhlIGRlZmluaXRpb24gb2YgdGhl ICdhY3RpdmUnIGNsYWltOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwO2FjdGl2ZTxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JFUVVJUkVELiAmbmJzcDtCb29sZWFuIGluZGljYXRv ciBvZiB3aGV0aGVyIG9yIG5vdCB0aGUgcHJlc2VudGVkIHRva2VuPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7aXMgY3VycmVudGx5IGFjdGl2ZS4gJm5ic3A7VGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGRldGVybWluZXMgd2hldGhlcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2FuZCB3aGVuIGEgZ2l2ZW4gdG9rZW4gaXMgaW4gYW4gYWN0aXZlIHN0YXRlLjxi cj4NCjxicj4NClRoaXMgY2xhaW0gaXMgbm90IHdlbGwtZGVmaW5lZC4gWW91IG5lZWQgdG8gZXhw bGFpbiB3aGF0ICZxdW90O2FjdGl2ZSZxdW90OyBtZWFucy48YnI+DQpJdCBjb3VsZCwgZm9yIGV4 YW1wbGUsIG1lYW4gdGhhdCB0aGUgdG9rZW4gaXMgbm90IHlldCBleHBpcmVkLiBUaGVuLDxicj4N CnRoZXJlIGlzIG9mIGNvdXJzZSB0aGUgcXVlc3Rpb24gd2h5IHlvdSBhcmUgbm90IHJldHVybmlu ZyB0aGUgJ2V4cCc8YnI+DQpjbGFpbSB0b2dldGhlciB3aXRoIHRoZSAnbmJmJyBjbGFpbS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRl ZmluaXRpb24gb2Yg4oCcYWN0aXZl4oCdIGlzIHJlYWxseSB1cCB0byB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIsIGFuZCBJ4oCZdmUgeWV0IHRvIGhlYXIgZnJvbSBhbiBhY3R1YWwgaW1wbGVtZW50 b3Igd2hv4oCZcyBjb25mdXNlZCBieSB0aGlzIGRlZmluaXRpb24uIFdoZW4geW914oCZcmUgdGhl IG9uZSBpc3N1aW5nIHRoZSB0b2tlbnMsIHlvdSBrbm93IHdoYXQgYW4g4oCcYWN0aXZl4oCdIHRv a2VuIG1lYW5zIHRvIHlvdS4NCiBTdGlsbCwgcGVyaGFwcyB3ZSBjYW4gYmUgZXZlbiBtb3JlIGV4 cGxpY2l0LCBzdWNoIGFzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWN0aXZlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgUkVRVUlSRUQuIEJvb2xl YW4gaW5kaWNhdG9yIG9mIHdoZXRoZXIgb3Igbm90IHRoZSBwcmVzZW50ZWQgdG9rZW4gaXMgY3Vy cmVudGx5IGFjdGl2ZS4gVGhlIHNwZWNpZmljcyBvZiBhIHRva2Vu4oCZcyBhY3RpdmUgc3RhdGUg d2lsbCB2YXJ5IGRlcGVuZGluZyBvbiB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyLCBidXQgZ2VuZXJhbGx5IHRoaXMgd2lsbCBpbmRpY2F0ZSB0aGF0DQogYSBn aXZlbiB0b2tlbiBoYXMgYmVlbiBpc3N1ZWQgYnkgdGhpcyBhdXRob3JpemF0aW9uIHNlcnZlciwg aGFzIG5vdCBiZWVuIHJldm9rZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCBhbmQgaXMgd2l0aGlu IGl0cyBnaXZlbiB0aW1lIHdpbmRvdyBvZiB2YWxpZGl0eSAoZS5nLiBub3QgZXhwaXJlZCkuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgdGhpcyBpcyBvbmUgb2YgdGhlIHBs YWNlcyB3aGVyZSB0aGUgb3ZlcmxhcCBiZXR3ZWVuIEpXVCBhbmQgaW50cm9zcGVjdGlvbiBjbGFp bXMgZG9u4oCZdCBtYWtlIHNlbnNlLiBJdCBkb2VzbuKAmXQgbWFrZSBhbnkgc2Vuc2UgZm9yIGEg SldUIHRvIGNhcnJ5IGFuIOKAnGFjdGl2ZeKAnSBjbGFpbSBhdCBhbGwuIFdoeSB3b3VsZCB5b3Ug aGF2ZSBhIEpXVCBjbGFpbSB0byBiZSBhbnl0aGluZyBidXQgYWN0aXZlPyBXZQ0KIHNob3VsZCBy ZWdpc3RlciBpdCB3aXRoIHRoZSBKV1QgcmVnaXN0cnkgdG8gYXZvaWQgbmFtZSBjb2xsaXNpb25z LCBidXQgdGhlcmXigJlzIG5vdGhpbmcgaW4gdGhlIEpXVCByZWdpc3RyeSB0aGF0IHNheXMg4oCc ZG9u4oCZdCB1c2UgdGhpcyBpbnNpZGUgb2YgYSBKV1TigJ0uIERvIHlvdSBoYXZlIGFueSBhZHZp Y2Ugb24gaG93IHRvIGFkZHJlc3MgdGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KY2xpZW50X2lkOiBXaGF0IGlzIHRoZSByZXNvdXJjZSBzZXJ2 ZXIgZ29pbmcgdG8gZG8gd2l0aCB0aGUgY2xpZW50X2lkPzxicj4NCldoYXQgYXV0aG9yaXphdGlv biBkZWNpc2lvbiBjb3VsZCBpdCBtYWtlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0ZXZlciBpdCB3YW50cyB0by4gSWYgYW4gUlMgY2Fu IGZpZ3VyZSBvdXQgc29tZXRoaW5nIGZyb20gdGhlIGNsaWVudF9pZCwgd2h5IG5vdCBsZXQgaXQ/ IFRoZSBjbGllbnRfaWQgaXMgYSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4 dCBvZiB0aGUgaXNzdWFuY2Ugb2YgdGhlIHRva2VuLCBhbmQgYSBjb21tb24gZW5vdWdoIE9BdXRo IHZhbHVlIGZvciBkZWNpc2lvbiBtYWtpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGNvdXBsZSBvZiByZWFjdGlvbnMgd2hlbiBJ IHJlYWQgdGhlICd1c2VyX2lkJyBjbGFpbTo8YnI+DQombmJzcDstIEkgYmVsaWV2ZSB0aGUgaW5j bHVzaW9uIG9mIGEgdXNlciBpZCBmaWVsZCBpbiB0aGUgcmVzcG9uc2UgY291bGQ8YnI+DQpsZWFk IHRvIGZ1cnRoZXIgY29uZnVzaW9uIHJlZ2FyZGluZyBPQXV0aCBhY2Nlc3MgdG9rZW4gdXNhZ2Ug Zm9yPGJyPg0KYXV0aGVudGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXNu4oCZdCBhbnkgZGlmZmVyZW50IGZyb20gaGF2 aW5nIGEgdXNlcmluZm8tZW5kcG9pbnQgZXF1aXZhbGVudCAobGlrZSBzb2NpYWwgZ3JhcGggb3Ig dHdpdHRlciBBUEkpIGFuZCBpdOKAmXMgZ290IHRoZSBzYW1lIHRyb3VibGUuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwOy0gU2lu Y2UgeW91IGRlZmluZSBpdCBhcyBhIGh1bWFuIHJlYWRhYmxlIGlkZW50aWZpZXIgSSBhbSB3b25k ZXJpbmc8YnI+DQp3aGV0aGVyIHlvdSB3YW50IHRvIHNheSBzb21ldGhpbmcgYWJvdXQgdGhlIHVz YWdlLiBIZXJlIGl0IHNlZW1zIHRoYXQgaXQ8YnI+DQptaWdodCBiZSB1c2VkIGZvciBkaXNwbGF5 aW5nIHNvbWV0aGluZyBvbiBhIHdlYnBhZ2UgcmF0aGVyIHRoYW4gbWFraW5nPGJyPg0KYW4gYXV0 aG9yaXphdGlvbiBkZWNpc2lvbiBidXQgSSBtaWdodCB3ZWxsIGJlIHdyb25nLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhZGRlZCBpbiDi gJx1c2VyX2lk4oCdIHRvIG91ciBpbXBsZW1lbnRhdGlvbiBkdWUgdG8gZGV2ZWxvcGVyIGRlbWFu ZCDigJQgdGhleSB3YW50ZWQgYSB1c2VybmFtZSBhc3NvY2lhdGVkIHdpdGggdGhlIHJldHVybiB2 YWx1ZSwgYnV0IHRvIGxlYXZlIHRoZSDigJxzdWLigJ0gdmFsdWUgdGhlIHNhbWUgYXMgdGhhdCBk ZWZpbmVkIGJ5IE9wZW5JRCBDb25uZWN0LiBOb3RlIHRoYXQgdGhpcyBpcyBpbiBhbiBlbnZpcm9u bWVudA0KIHdoZXJlIHRoZSB1c2VybmFtZSBpcyBhIGtub3duIHF1YW50aXR5LCBhbmQgdGhleeKA mXJlIG5vdCB0cnlpbmcgdG8gZG8gY3Jvc3MtZG9tYWluIGF1dGhlbnRpY2F0aW9uLiBUaGV5IGp1 c3Qgd2FudCB0byBrbm93IHdob3NlIHRva2VuIHRoaXMgd2FzIHNvIHRoZXkgY2FuIGZpZ3VyZSBv dXQgd2hvc2UgZGF0YSB0byByZXR1cm4uIEl04oCZcyBub3QgdXNlZCBmb3IgZGlzcGxheSwgYnV0 IEkgdHJpZWQgdG8gbWFrZSB0aGUgZGVmaW5pdGlvbiBpbiBjb250cmFzdA0KIHRvIHRoZSBtYWNo aW5lLWZhY2luZyDigJxzdWLigJ0gdmFsdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwOy0gSSBhbSBtaXNzaW5nIGEgZGlzY3Vzc2lvbiBh Ym91dCB0aGUgcHJpdmFjeSBpbXBsaWNhdGlvbnMgb2YgaXQuPGJyPg0KV2hpbGUgdGhlcmUgaXMg YSBwcml2YWN5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBJIGFtIHdvbmRlcmluZyB3aGF0PGJyPg0K Y29udHJvbHMgdGhlIHJlbGVhc2Ugb2YgdGhpcyBzZW5zaXRpdmUgaW5mb3JtYXRpb24gZnJvbSB0 aGU8YnI+DQphdXRob3JpemF0aW9uIHNlcnZlciB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLiBXaGls ZSBpbiBzb21lIGNhc2VzIHRoZSB0d288YnI+DQpwYXJ0aWVzIG1pZ2h0IGJlbG9uZyB0byB0aGUg c2FtZSBvcmdhbml6YXRpb24gYnV0IGluIG90aGVyIGNhc2VzIHRoYXQ8YnI+DQptYXkgbm90IG5l Y2Vzc2FyaWx5IGJlIHRydWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPllvdeKAmXJlIGNvcnJlY3QsIHRoaXMgaXMgY3VycmVudGx5IG1pc3Np bmcgYW5kIEnigJlsbCBhZGQgdGhhdCBpbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7LSBJbiB0ZXJtcyBvZiB0aGUgaW5mb3JtYXRpb24g ZXhjaGFuZ2VkIGFib3V0IHRoZSB1c2VyIEkgYW0gY3VyaW91czxicj4NCmFib3V0IHRoZSB1c2Vm dWxuZXNzIG9mIGluY2x1ZGluZyBvdGhlciBpbmZvcm1hdGlvbiBhcyB3ZWxsLCBzdWNoIGFzIHRo ZTxicj4NCmluZm8gdGhhdCBpcyBpbmNsdWRlZCBpbiBhbiBpZCB0b2tlbiAoc2VlPGJyPg0KPGEg aHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRt bCNJRFRva2VuIj5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFf MC5odG1sI0lEVG9rZW48L2E+KS4gSWYgdGhpczxicj4NCmhhcyBub3RoaW5nIHRvIGRvIHdpdGgg dGhlIElEIHRva2VuIGNvbmNlcHQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjYXJyaWVkPGJyPg0Kd2l0 aGluIGl0IHRoZW4gSSB3b3VsZCBhZGQgdGhhdCByZW1hcmsuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGNvdWxkIGludHJvc3BlY3Qg YW4gSUQgdG9rZW4gaWYgeW91IHdhbnRlZCB0bywgYnV0IGl04oCZcyB1c3VhbGx5IGVhc2llciB0 byBqdXN0IHBhcnNlIGl0IHlvdXJzZWxmIGJlY2F1c2UgaXTigJlzIHNlbGYtY29udGFpbmVkLiBU aGUgSUQgVG9rZW4gYWxzbyBleHRlbmRzIEpXVCwgc28gdGhlcmXigJlzIG5vdGhpbmcgc3RvcHBp bmcgeW91IGZyb20gcmV0dXJuaW5nIHRob3NlIGNsYWltcyBhcyB3ZWxsLiBIb3dldmVyLA0KIG5v dGUgdGhhdCB0aGUgYXVkaWVuY2Ugb2YgdGhlIElEIHRva2VuIGlzIHRoZSBPQXV0aCAqY2xpZW50 KiB3aGVyZWFzIHRoZSB0YXJnZXRlZCB1c2VyIG9mIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50 IGlzIHRoZSAqcHJvdGVjdGVkIHJlc291cmNlKi4gVGhlIFBSIGlzbuKAmXQgZ29pbmcgdG8gc2Vl IHRoZSBJRCBUb2tlbiBtb3N0IG9mIHRoZSB0aW1lLCBhbmQgdGhlIGNsaWVudOKAmXMgbm90IGdv aW5nIHRvIG5lZWQgdG8gKG9yIGJlIGFibGUgdG8pDQogaW50cm9zcGVjdCBpdHMgdG9rZW5zIG1v c3Qgb2YgdGhlIHRpbWUsIHNvIGluIHByYWN0aWNlIHRoZXJl4oCZcyBub3QgcmVhbGx5IGFueSBv dmVybGFwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCkNpYW88YnI+DQpIYW5uZXM8YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B1680429673943A2E78D9FTK5EX14MBXC292r_-- From nobody Wed Mar 4 15:34:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757501A0067 for ; Wed, 4 Mar 2015 15:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 L1X1yZ4jnAGE for ; Wed, 4 Mar 2015 15:34:35 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467BD1A005C for ; Wed, 4 Mar 2015 15:34:35 -0800 (PST) Received: from BY2PR03CA002.namprd03.prod.outlook.com (10.255.93.19) by DM2PR0301MB0624.namprd03.prod.outlook.com (25.160.95.28) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 4 Mar 2015 23:34:33 +0000 Received: from BY2FFO11FD023.protection.gbl (10.255.93.4) by BY2PR03CA002.outlook.office365.com (10.255.93.19) with Microsoft SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Wed, 4 Mar 2015 23:34:33 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 4 Mar 2015 23:34:33 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.74]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0224.003; Wed, 4 Mar 2015 23:33:52 +0000 From: Mike Jones To: Anthony Nadalin , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline Thread-Index: AQHQVolBIxzQq7Nzg0mQ91i99DI7Cp0M+AcAgAABVsA= Date: Wed, 4 Mar 2015 23:33:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E78DFF@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <54F71978.5090804@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; gmx.net; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(53754006)(199003)(377454003)(189002)(13464003)(2900100001)(2950100001)(2920100001)(50466002)(46406003)(66066001)(33656002)(561944003)(47776003)(23726002)(2561002)(62966003)(77156002)(54356999)(50986999)(104016003)(2501003)(107886001)(19580405001)(19580395003)(106116001)(55846006)(86612001)(85806002)(2421001)(76176999)(46102003)(230783001)(102836002)(97756001)(86362001)(6806004)(2656002)(87936001)(106466001)(15975445007)(92566002)(1511001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0624; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0624; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002007)(5005006); SRVR:DM2PR0301MB0624; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0624; X-Forefront-PRVS: 0505147DDB X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2015 23:34:33.1836 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0624 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 23:34:37 -0000 It does so for the same reason that the JWT spec does - to promote interope= rability. We can add wording along the likes of "the JWE Compact Serializa= tion MUST be used" if you like. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Wednesday, March 04, 2015 3:26 PM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Op= en Issues before the Deadline Why does the specification state "encrypted to a key known to the recipient= using the JWE Compact Serialization" is this the only serialization allowe= d (there is no MUST) ? containing the symmetric key. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, March 4, 2015 6:41 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open I= ssues before the Deadline Hi all, as the deadline is approaching I would like to close the open issues of the= document. There are two open issues listed in the document and I propose w= ays to resolve them below Open Issue #1: "In some conversations, we have said that it is the issuer of the JWT that possesses the key, and in some conversations, we have said that it is the presenter of the JWT that possesses the key. Which description should we use? " There are the following parties in the entire picture (as the PoP architect= ure document illustrates quite nicely): * Issuer: Party that creates the JWT and binds a key to the token. The key may be a symmetric key or a public key. To bind the key to the JWT = the issuer needs to compute a digital signature or a keyed message digest o= ver the JWT. * Presenter: Party that demonstrates possession of a private key (for asymm= etric key cryptography) and secret key (for symmetric key cryptography) to a recipient. * Recipient: Party that receives the JWT together with the proof of possess= ion of the key (typically in form of a digital signature or a keyed message= digest). Mapping this terminology to the OAuth context would look as follows: - Issuer: OAuth Authorization Server - Presenter: OAuth Client - Recipient: OAuth Resource Server Adding the above-mentioned terminology to the terminology section (and dele= ting the currently listed presenter) would resolve the issue IMHO. Open Issue#2: Mike added an editorial note to the introduction saying: " [[ Editorial Note: This paragraph needs to be updated to provide more context and possibly also to describe the use of asymmetric keys instead. It's not clear that the symmetric case is as useful or valuable, and it is certainly more complicated.]] " The design team work clearly indicated that both symmetric and asymmetric c= ryptography has to be supported. The JWT mechanism actually supports both a= nd hence we should also describe both. What can, however, be done is to als= o describe the asymmetric key case and here is my text proposal for the int= roduction. ---- 1. Introduction This specification defines how to bind a key to a JSON Web Token (JWT) [JWT]. Three parties act in such a scenario: * Issuer: Party that creates the JWT and binds a key to the token. The key may be a symmetric key or a public key. To bind the key to the JWT = the issuer needs to compute a digital signature or a keyed message digest o= ver the JWT. * Presenter: Party that demonstrates possession of a private key (for asymm= etric key cryptography) and secret key (for symmetric key cryptography) to = a recipient. This property is also sometimes described as the presenter bei= ng a holder-of-key. * Recipient: Party that receives the JWT together with the proof of possess= ion of the key (typically in form of a digital signature or a keyed message= digest). [I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession = semantics for JSON Web Tokens (JWTs) for the use with OAuth. Envision the following two use cases. The first use case describes the use of a symmetric key and the second use case focuses on asymmetric cryptography. An OAuth 2.0 authorization server generates a JWT and places an encrypted symmetric key inside the newly introduced confirmation claim. This symmetric key is encrypted with a key known only to the authorization server and the recipient. The entire JWT is then integrity protected. The JWT is then sent to the presenter. Since the presenter is unable to obtain the encrypted symmetric key from the JWT itself, the authorization server conveys that symmetric key separately to the presenter. Now, the presenter is in possession of the symmetric key as well as the JWT (which includes the confirmation claim member). When the presenter needs to present the JWT to the recipient, it also needs to demonstrate possession of the symmetric key; the presenter, for example, uses the symmetric key in a challenge/response protocol with the recipient. The recipient is able to verify that it is interacting with the genuine presenter by decrypting the JWK contained inside the confirmation claim of the JWT. By doing this the recipient obtains the symmetric key, which it then uses to verify cryptographically protected messages exchanged with the presenter. This symmetric key mechanism described above is conceptually similar to the use of Kerberos tickets. In the second case consider a presenter that generates a public / private key pair. It then sends the public key to an OAuth 2.0 authorization server, which creates a JWT and places an public key (or a fingerprint of it) inside the newly introduced confirmation claim. The entire JWT is then integrity protected using a digital signature to protect it against modifications. The JWT is then sent to the presenter. When the presenter needs to present the JWT to the recipient, it also needs to demonstrate possession of the private key. The presenter, for example, uses the private key in TLS exchange with the recipient. The recipient is able to verify that it is interacting with the genuine presenter by extracting the public key from the confirmation claim of the JWT (after verifying the digital signature of the JWT) and utilizing it with the private key in the TLS exchange. The asymmetric key mechanism described above is conceptually similar to a certificate. In both cases the JWT may contain various claims that are included based on the policy of the authorization server. ---- Due to the IETF draft submission deadline we would appreciate a response by= next Sunday. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Mar 4 18:43:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4E1AD1A3 for ; Wed, 4 Mar 2015 18:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 o7j_BYK5C7uq for ; Wed, 4 Mar 2015 18:43:14 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AED1AD190 for ; Wed, 4 Mar 2015 18:43:14 -0800 (PST) X-AuditID: 1209190e-f79bb6d0000030e8-9e-54f7c2c0f882 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 51.3C.12520.0C2C7F45; Wed, 4 Mar 2015 21:43:12 -0500 (EST) 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 t252hBpv011064; Wed, 4 Mar 2015 21:43:12 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t252hAu7022006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2015 21:43:11 -0500 Message-ID: <54F7C2B7.7090304@mit.edu> Date: Wed, 04 Mar 2015 21:43:03 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mike Jones , Hannes Tschofenig References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------030005090508000404060607" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6nrnvg0PcQg74GY4ulO++xWuyd9onF 4uTbV2wOzB6LN+1n81iy5CeTR+uOv+wBzFFcNimpOZllqUX6dglcGcdnnmQu2DuJqWL1/H9s DYznDjN2MXJySAiYSBz99IMJwhaTuHBvPVsXIxeHkMBiJolze16xQDgbGCU2PWxkh3BuMUn8 vTaZDaSFV0BN4mH3S2YQm0VAVeLCh04wmw3Inr6mBWysqECURM+fbqh6QYmTM5+wgNgiAikS F5oXgdUwC6hL9P5eyQpiCwsESKzYdpIVYtkqRoknP16xgyQ4BRIlbt3fwgbRECYxc30L0wRG gVlI5s5CkoKwzSTmbX7IDGHLSzRvnQ1kcwDZahLLWpWQhRcwsq1ilE3JrdLNTczMKU5N1i1O TszLSy3SNdbLzSzRS00p3cQIigVOSb4djF8PKh1iFOBgVOLh/bD5e4gQa2JZcWXuIUZJDiYl Ud6NjUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwPpwPleFMSK6tSi/JhUtIcLErivJt+8IUI CaQnlqRmp6YWpBbBZGU4OJQkeFsOAjUKFqWmp1akZeaUIKSZODhBhvMADW8FqeEtLkjMLc5M h8ifYlSUEud9AJIQAElklObB9cJS1StGcaBXhHlFgYlLiAeY5uC6XwENZgIafEvxC8jgkkSE lFQDY5TIv6hn+zQUXX5HHTF6ldIlLO50ZO/irdOWKkjlLDdj9n4XtFJ+Vkag5NKdW9KupE+R 6T+277rpM9/cGxK/jD6mpkyyuKJiUe6XNXNCaEr43ZD1sxW2nN9hc9bxV2ZIzxTJ3tl7GQvu eRcukO6K3Jfbxf72v0r3tJ4f1kWvdNp0K3Jq1P7/VGIpzkg01GIuKk4EAJ5GB58wAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 02:43:19 -0000 This is a multi-part message in MIME format. --------------030005090508000404060607 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on "active" and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially "active", which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing "user_id" to "username", since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with "preffered_username" in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than "active", "scope", or "client_id" would be. For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft. Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the "JWT registry", and now it's got hangings of being "JWT-specific". When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific. -- Justin [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 [2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim On 3/4/2015 6:28 PM, Mike Jones wrote: > > I have severe concerns with this approach. It’s not appropriate to > register arbitrary JSON object member names as JWT claim names – > especially when the JSON object member names are not even being used > as JWT claim names. *Please do not do this*, as it would needlessly > pollute the JWT claim name namespace with registered names that are > application specific. > > Secondarily, I have concerns about these names and suggestions for how > to address them. > > “active” – This claim is not presently adequately defined. And its > definition will of necessity be specific to the introspection > application. Therefore, it should not be registered as a general JWT > claim name. A name I would be comfortable with for this concept would > be urn:ietf:params:oauth:introspection:active, since it makes it clear > what application the name is used with. > > “user_id” – The concept you’re describing is almost universally called > “username”. User ID is typically the numeric account identifier > (carried in the “sub” claim in a JWT), and so is not the right name > for this. Compare it to the preferred_username claim in OpenID > Connect. Please change this either to “username” or > urn:ietf:params:oauth:introspection:username. > > “token_type” – While this is well-defined, the usage is fairly > specific to this application. Again, adding the > urn:ietf:params:oauth:introspection: name prefix would address this issue. > > If you give up registering these names in the JWT Claims registry, I’m > OK with you using short names. But if you want them to live alongside > other JWT claim names, please include the > urn:ietf:params:oauth:introspection: in lieu of registration. > > Thank you, > > -- Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer > *Sent:* Wednesday, March 04, 2015 1:46 PM > *To:* Hannes Tschofenig > *Cc:* > *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token > Introspection "Claims" > > Hi Hannes, thanks for the feedback. Responses inline. > > On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig > > wrote: > > Hi Justin, Hi all, > > in OAuth we provide two ways for a resource server to make an > authorization decision. > > 1) The resource server receives a self-contained token that > contains all > the necessary information to make a local authorization decision. With > the JWT we have created such a standardized information and data > model. > > 2) With an access request from a client the resource server asks the > authorization server for "help". The authorization server provides > information that help make the authorization decision. This is the > token > introspection approach. > > I believe the two approaches need to be aligned with regard to the > information and the data model. Since both documents already use > JSON as > a way to encode information (=data model) and almost have an identical > information model (the data that is being passed around). > > What needs to be done? > > * Use the term 'claims' in both documents. > * Use the same registry (i.e., the registry established with the JWT). > * Register the newly defined claims from the token introspection > document in the claims registry. > > We’ve already done this in the latest draft. Or at least, that’s the > intent of the current text — the registry is referenced and the new > claims are registered. Can you specifically point to places where this > needs to be improved upon? > > > > Then, I have a few comments on the new claims that are proposed: > > Here is the definition of the 'active' claim: > > active > REQUIRED. Boolean indicator of whether or not the presented token > is currently active. The authorization server determines whether > and when a given token is in an active state. > > This claim is not well-defined. You need to explain what "active" means. > It could, for example, mean that the token is not yet expired. Then, > there is of course the question why you are not returning the 'exp' > claim together with the 'nbf' claim. > > The definition of “active” is really up to the authorization server, > and I’ve yet to hear from an actual implementor who’s confused by this > definition. When you’re the one issuing the tokens, you know what an > “active” token means to you. Still, perhaps we can be even more > explicit, such as: > > active > > REQUIRED. Boolean indicator of whether or not the presented > token is currently active. The specifics of a token’s active state > will vary depending on the implementation of the authorization > server, but generally this will indicate that a given token has > been issued by this authorization server, has not been revoked by > the resource owner, and is within its given time window of > validity (e.g. not expired). > > Also, this is one of the places where the overlap between JWT and > introspection claims don’t make sense. It doesn’t make any sense for a > JWT to carry an “active” claim at all. Why would you have a JWT claim > to be anything but active? We should register it with the JWT registry > to avoid name collisions, but there’s nothing in the JWT registry that > says “don’t use this inside of a JWT”. Do you have any advice on how > to address this? > > > > > client_id: What is the resource server going to do with the client_id? > What authorization decision could it make? > > Whatever it wants to. If an RS can figure out something from the > client_id, why not let it? The client_id is a piece of information > about the context of the issuance of the token, and a common enough > OAuth value for decision making. > > > > I have a couple of reactions when I read the 'user_id' claim: > - I believe the inclusion of a user id field in the response could > lead to further confusion regarding OAuth access token usage for > authentication. > > This isn’t any different from having a userinfo-endpoint equivalent > (like social graph or twitter API) and it’s got the same trouble. > > > > > - Since you define it as a human readable identifier I am wondering > whether you want to say something about the usage. Here it seems that it > might be used for displaying something on a webpage rather than making > an authorization decision but I might well be wrong. > > We added in “user_id” to our implementation due to developer demand — > they wanted a username associated with the return value, but to leave > the “sub” value the same as that defined by OpenID Connect. Note that > this is in an environment where the username is a known quantity, and > they’re not trying to do cross-domain authentication. They just want > to know whose token this was so they can figure out whose data to > return. It’s not used for display, but I tried to make the definition > in contrast to the machine-facing “sub” value. > > > > > - I am missing a discussion about the privacy implications of it. > While there is a privacy consideration section I am wondering what > controls the release of this sensitive information from the > authorization server to the resource server. While in some cases the two > parties might belong to the same organization but in other cases that > may not necessarily be true. > > You’re correct, this is currently missing and I’ll add that in. > > > > > - In terms of the information exchanged about the user I am curious > about the usefulness of including other information as well, such as the > info that is included in an id token (see > http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this > has nothing to do with the ID token concept and the information carried > within it then I would add that remark. > > You could introspect an ID token if you wanted to, but it’s usually > easier to just parse it yourself because it’s self-contained. The ID > Token also extends JWT, so there’s nothing stopping you from returning > those claims as well. However, note that the audience of the ID token > is the OAuth *client* whereas the targeted user of the introspection > endpoint is the *protected resource*. The PR isn’t going to see the ID > Token most of the time, and the client’s not going to need to (or be > able to) introspect its tokens most of the time, so in practice > there’s not really any overlap. > > — Justin > > > > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------030005090508000404060607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on "active" and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially "active", which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing "user_id" to "username", since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with "preffered_username" in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than "active", "scope", or "client_id" would be.

For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft.

Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the "JWT registry", and now it's got hangings of being "JWT-specific". When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific.

 -- Justin

[1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03
[2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim

On 3/4/2015 6:28 PM, Mike Jones wrote:

I have severe concerns with this approach.  It’s not appropriate to register arbitrary JSON object member names as JWT claim names – especially when the JSON object member names are not even being used as JWT claim names.  Please do not do this, as it would needlessly pollute the JWT claim name namespace with registered names that are application specific.

 

Secondarily, I have concerns about these names and suggestions for how to address them.

 

“active” – This claim is not presently adequately defined.  And its definition will of necessity be specific to the introspection application.  Therefore, it should not be registered as a general JWT claim name.  A name I would be comfortable with for this concept would be urn:ietf:params:oauth:introspection:active, since it makes it clear what application the name is used with.

 

“user_id” – The concept you’re describing is almost universally called “username”.  User ID is typically the numeric account identifier (carried in the “sub” claim in a JWT), and so is not the right name for this.  Compare it to the preferred_username claim in OpenID Connect.  Please change this either to “username” or urn:ietf:params:oauth:introspection:username.

 

“token_type” – While this is well-defined, the usage is fairly specific to this application.  Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue.

 

If you give up registering these names in the JWT Claims registry, I’m OK with you using short names.  But if you want them to live alongside other JWT claim names, please include the urn:ietf:params:oauth:introspection: in lieu of registration.

 

                                                            Thank you,

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, March 04, 2015 1:46 PM
To: Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

 

Hi Hannes, thanks for the feedback. Responses inline.

 

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

 

Hi Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=data model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

* Use the term 'claims' in both documents.
* Use the same registry (i.e., the registry established with the JWT).
* Register the newly defined claims from the token introspection
document in the claims registry.

 

We’ve already done this in the latest draft. Or at least, that’s the intent of the current text — the registry is referenced and the new claims are registered. Can you specifically point to places where this needs to be improved upon?



Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

  active
     REQUIRED.  Boolean indicator of whether or not the presented token
     is currently active.  The authorization server determines whether
     and when a given token is in an active state.

This claim is not well-defined. You need to explain what "active" means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

 

The definition of “active” is really up to the authorization server, and I’ve yet to hear from an actual implementor who’s confused by this definition. When you’re the one issuing the tokens, you know what an “active” token means to you. Still, perhaps we can be even more explicit, such as:

 

 

active

  REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token’s active state will vary depending on the implementation of the authorization server, but generally this will indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g. not expired). 

 

Also, this is one of the places where the overlap between JWT and introspection claims don’t make sense. It doesn’t make any sense for a JWT to carry an “active” claim at all. Why would you have a JWT claim to be anything but active? We should register it with the JWT registry to avoid name collisions, but there’s nothing in the JWT registry that says “don’t use this inside of a JWT”. Do you have any advice on how to address this?




client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

 

Whatever it wants to. If an RS can figure out something from the client_id, why not let it? The client_id is a piece of information about the context of the issuance of the token, and a common enough OAuth value for decision making. 



I have a couple of reactions when I read the 'user_id' claim:
 - I believe the inclusion of a user id field in the response could
lead to further confusion regarding OAuth access token usage for
authentication.

 

This isn’t any different from having a userinfo-endpoint equivalent (like social graph or twitter API) and it’s got the same trouble. 




 - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

 

We added in “user_id” to our implementation due to developer demand — they wanted a username associated with the return value, but to leave the “sub” value the same as that defined by OpenID Connect. Note that this is in an environment where the username is a known quantity, and they’re not trying to do cross-domain authentication. They just want to know whose token this was so they can figure out whose data to return. It’s not used for display, but I tried to make the definition in contrast to the machine-facing “sub” value.




 - I am missing a discussion about the privacy implications of it.
While there is a privacy consideration section I am wondering what
controls the release of this sensitive information from the
authorization server to the resource server. While in some cases the two
parties might belong to the same organization but in other cases that
may not necessarily be true.

 

You’re correct, this is currently missing and I’ll add that in.




 - In terms of the information exchanged about the user I am curious
about the usefulness of including other information as well, such as the
info that is included in an id token (see
http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this
has nothing to do with the ID token concept and the information carried
within it then I would add that remark.

 

 

You could introspect an ID token if you wanted to, but it’s usually easier to just parse it yourself because it’s self-contained. The ID Token also extends JWT, so there’s nothing stopping you from returning those claims as well. However, note that the audience of the ID token is the OAuth *client* whereas the targeted user of the introspection endpoint is the *protected resource*. The PR isn’t going to see the ID Token most of the time, and the client’s not going to need to (or be able to) introspect its tokens most of the time, so in practice there’s not really any overlap.

 

 — Justin




Ciao
Hannes

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

 


--------------030005090508000404060607-- From nobody Wed Mar 4 23:37:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B871B2A0F for ; Wed, 4 Mar 2015 23:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 D4SmOLqO6E0C for ; Wed, 4 Mar 2015 23:37:31 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C391B2A04 for ; Wed, 4 Mar 2015 23:37:31 -0800 (PST) Received: from CO2PR03CA0045.namprd03.prod.outlook.com (10.141.194.172) by DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.99.9; Thu, 5 Mar 2015 07:37:29 +0000 Received: from BN1BFFO11FD007.protection.gbl (2a01:111:f400:7c10::1:103) by CO2PR03CA0045.outlook.office365.com (2a01:111:e400:1414::44) with Microsoft SMTP Server (TLS) id 15.1.99.9 via Frontend Transport; Thu, 5 Mar 2015 07:37:29 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD007.mail.protection.outlook.com (10.58.144.70) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Thu, 5 Mar 2015 07:37:28 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.74]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0224.002; Thu, 5 Mar 2015 07:36:53 +0000 From: Mike Jones To: Justin Richer , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" Thread-Index: AQHQVaC54CohmDLCbEuXvzRHTtpjuJ0M3fEAgAAJBZCAAEn8gIAAUhhI Date: Thu, 5 Mar 2015 07:36:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> In-Reply-To: <54F7C2B7.7090304@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2E79640TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; mit.edu; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(438002)(189002)(51914003)(24454002)(377454003)(479174004)(53754006)(199003)(15584002)(6806004)(19580395003)(19580405001)(33656002)(55846006)(86362001)(15395725005)(106116001)(92566002)(104016003)(16236675004)(19625215002)(102836002)(84326002)(15975445007)(2900100001)(2920100001)(2950100001)(19617315012)(62966003)(77156002)(87936001)(2656002)(2171001)(76176999)(54356999)(86612001)(50986999)(106466001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001007); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; X-Forefront-PRVS: 05066DEDBB X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2015 07:37:28.1301 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 07:37:35 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943A2E79640TK5EX14MBXC292r_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable It sounds to me like you're making a good argument for this spec to have it= s own registry. Registries are easy to establish and use. ________________________________ From: Justin Richer Sent: =FD3/=FD4/=FD2015 6:43 PM To: Mike Jones; Hannes Tschofenig Cc: Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Cl= aims" I'm actually fine with keeping the introspection-specific elements out of t= he registry (see my note on "active" and how it doesn't fit in JWT below), = but I do not want to give up the short names. The short names are already i= n production, especially "active", which is well understood and used in pra= ctice today, and has been for years[1]. Changing this would fundamentally b= reak all existing implementations for no good reason. I'm slightly more OK = with changing "user_id" to "username", since that's not as widely deployed = to my knowledge (other implementers, please pipe up if I'm mistaken), and I= 'm well familiar with "preffered_username" in OIDC because I'm the one that= put it in there [2]. :) While I prefer to leave it be at this stage, I thi= nk this is a less destructive change than "active", "scope", or "client_id"= would be. For background to my stance regarding the registry: several revisions (and = years) ago, the introspection draft re-defined several fields that overlapp= ed with JWT and we were asked to correlate the two. Originally, we simply h= ad a pointer to re-use the JWT claims as defined, and stacked our own claim= s on top. Later, we were asked to outright merge them, which is what we hav= e right now. If the WG wants to back off that last change to the middle sta= te -- where we re-use the JWT registry but don't write to it -- I'm very ha= ppy with that result and can work that (back) into the next draft. Though it does point out something strange about the standards process that= we're running into here: JWT needed a place to register bits of metadata a= bout a token, so it created one. This became the "JWT registry", and now it= 's got hangings of being "JWT-specific". When introspection came along with= a need to talk about much the same kind of information, it makes sense to = re-use the existing items but also that there would be things that are intr= ospection-specific. -- Justin [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 [2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim On 3/4/2015 6:28 PM, Mike Jones wrote: I have severe concerns with this approach. It=92s not appropriate to regis= ter arbitrary JSON object member names as JWT claim names =96 especially wh= en the JSON object member names are not even being used as JWT claim names.= Please do not do this, as it would needlessly pollute the JWT claim name = namespace with registered names that are application specific. Secondarily, I have concerns about these names and suggestions for how to a= ddress them. =93active=94 =96 This claim is not presently adequately defined. And its d= efinition will of necessity be specific to the introspection application. = Therefore, it should not be registered as a general JWT claim name. A name= I would be comfortable with for this concept would be urn:ietf:params:oaut= h:introspection:active, since it makes it clear what application the name i= s used with. =93user_id=94 =96 The concept you=92re describing is almost universally cal= led =93username=94. User ID is typically the numeric account identifier (c= arried in the =93sub=94 claim in a JWT), and so is not the right name for t= his. Compare it to the preferred_username claim in OpenID Connect. Please= change this either to =93username=94 or urn:ietf:params:oauth:introspectio= n:username. =93token_type=94 =96 While this is well-defined, the usage is fairly specif= ic to this application. Again, adding the urn:ietf:params:oauth:introspect= ion: name prefix would address this issue. If you give up registering these names in the JWT Claims registry, I=92m OK= with you using short names. But if you want them to live alongside other = JWT claim names, please include the urn:ietf:params:oauth:introspection: in= lieu of registration. Thank you, -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, March 04, 2015 1:46 PM To: Hannes Tschofenig Cc: Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Cl= aims" Hi Hannes, thanks for the feedback. Responses inline. On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig > wrote: Hi Justin, Hi all, in OAuth we provide two ways for a resource server to make an authorization decision. 1) The resource server receives a self-contained token that contains all the necessary information to make a local authorization decision. With the JWT we have created such a standardized information and data model. 2) With an access request from a client the resource server asks the authorization server for "help". The authorization server provides information that help make the authorization decision. This is the token introspection approach. I believe the two approaches need to be aligned with regard to the information and the data model. Since both documents already use JSON as a way to encode information (=3Ddata model) and almost have an identical information model (the data that is being passed around). What needs to be done? * Use the term 'claims' in both documents. * Use the same registry (i.e., the registry established with the JWT). * Register the newly defined claims from the token introspection document in the claims registry. We=92ve already done this in the latest draft. Or at least, that=92s the in= tent of the current text =97 the registry is referenced and the new claims = are registered. Can you specifically point to places where this needs to be= improved upon? Then, I have a few comments on the new claims that are proposed: Here is the definition of the 'active' claim: active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. This claim is not well-defined. You need to explain what "active" means. It could, for example, mean that the token is not yet expired. Then, there is of course the question why you are not returning the 'exp' claim together with the 'nbf' claim. The definition of =93active=94 is really up to the authorization server, an= d I=92ve yet to hear from an actual implementor who=92s confused by this de= finition. When you=92re the one issuing the tokens, you know what an =93act= ive=94 token means to you. Still, perhaps we can be even more explicit, suc= h as: active REQUIRED. Boolean indicator of whether or not the presented token is curr= ently active. The specifics of a token=92s active state will vary depending= on the implementation of the authorization server, but generally this will= indicate that a given token has been issued by this authorization server, = has not been revoked by the resource owner, and is within its given time wi= ndow of validity (e.g. not expired). Also, this is one of the places where the overlap between JWT and introspec= tion claims don=92t make sense. It doesn=92t make any sense for a JWT to ca= rry an =93active=94 claim at all. Why would you have a JWT claim to be anyt= hing but active? We should register it with the JWT registry to avoid name = collisions, but there=92s nothing in the JWT registry that says =93don=92t = use this inside of a JWT=94. Do you have any advice on how to address this? client_id: What is the resource server going to do with the client_id? What authorization decision could it make? Whatever it wants to. If an RS can figure out something from the client_id,= why not let it? The client_id is a piece of information about the context = of the issuance of the token, and a common enough OAuth value for decision = making. I have a couple of reactions when I read the 'user_id' claim: - I believe the inclusion of a user id field in the response could lead to further confusion regarding OAuth access token usage for authentication. This isn=92t any different from having a userinfo-endpoint equivalent (like= social graph or twitter API) and it=92s got the same trouble. - Since you define it as a human readable identifier I am wondering whether you want to say something about the usage. Here it seems that it might be used for displaying something on a webpage rather than making an authorization decision but I might well be wrong. We added in =93user_id=94 to our implementation due to developer demand =97= they wanted a username associated with the return value, but to leave the = =93sub=94 value the same as that defined by OpenID Connect. Note that this = is in an environment where the username is a known quantity, and they=92re = not trying to do cross-domain authentication. They just want to know whose = token this was so they can figure out whose data to return. It=92s not used= for display, but I tried to make the definition in contrast to the machine= -facing =93sub=94 value. - I am missing a discussion about the privacy implications of it. While there is a privacy consideration section I am wondering what controls the release of this sensitive information from the authorization server to the resource server. While in some cases the two parties might belong to the same organization but in other cases that may not necessarily be true. You=92re correct, this is currently missing and I=92ll add that in. - In terms of the information exchanged about the user I am curious about the usefulness of including other information as well, such as the info that is included in an id token (see http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this has nothing to do with the ID token concept and the information carried within it then I would add that remark. You could introspect an ID token if you wanted to, but it=92s usually easie= r to just parse it yourself because it=92s self-contained. The ID Token als= o extends JWT, so there=92s nothing stopping you from returning those claim= s as well. However, note that the audience of the ID token is the OAuth *cl= ient* whereas the targeted user of the introspection endpoint is the *prote= cted resource*. The PR isn=92t going to see the ID Token most of the time, = and the client=92s not going to need to (or be able to) introspect its toke= ns most of the time, so in practice there=92s not really any overlap. =97 Justin Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B1680429673943A2E79640TK5EX14MBXC292r_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
It sounds to = me like you're making a good argument for this spec to have its own registr= y.  Registries are easy to establish and use.
From: Justin Richer
Sent: =FD3/= =FD4/=FD2015 6:43 PM
To: Mike Jones; Hannes Tschofenig Cc: <oauth@ietf.org>
Subject: Re: [= OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"= ;

I'm actually fine with keeping the introspection-specific elements out= of the registry (see my note on "active" and how it doesn't fit = in JWT below), but I do not want to give up the short names. The short name= s are already in production, especially "active", which is well understood and used in practice today, and has been for year= s[1]. Changing this would fundamentally break all existing implementations = for no good reason. I'm slightly more OK with changing "user_id" = to "username", since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistak= en), and I'm well familiar with "preffered_username" in OIDC beca= use I'm the one that put it in there [2]. :) While I prefer to leave it be = at this stage, I think this is a less destructive change than "active", "scope", or "client_id"= ; would be.

For background to my stance regarding the registry: several revisions (and = years) ago, the introspection draft re-defined several fields that overlapp= ed with JWT and we were asked to correlate the two. Originally, we simply h= ad a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to out= right merge them, which is what we have right now. If the WG wants to back = off that last change to the middle state -- where we re-use the JWT registr= y but don't write to it -- I'm very happy with that result and can work that (back) into the next draft.

Though it does point out something strange about the standards process that= we're running into here: JWT needed a place to register bits of metadata a= bout a token, so it created one. This became the "JWT registry", = and now it's got hangings of being "JWT-specific". When introspection came along with a need to talk about much the same kind= of information, it makes sense to re-use the existing items but also that = there would be things that are introspection-specific.

 -- Justin

[1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03
[2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim<= br>
On 3/4/2015 6:28 PM, Mike Jones wrote:

I have severe concerns = with this approach.  It=92s not appropriate to register arbitrary JSON= object member names as JWT claim names =96 especially when the JSON object member names are not even being used as JWT claim names.  P= lease do not do this, as it would needlessly pollute the JWT claim name= namespace with registered names that are application specific.

 

Secondarily, I have con= cerns about these names and suggestions for how to address them.

 

=93active=94 =96 This c= laim is not presently adequately defined.  And its definition will of = necessity be specific to the introspection application.  Therefore, it should not be registered as a general JWT claim name.  A name I wo= uld be comfortable with for this concept would be urn:ietf:params:oauth:int= rospection:active, since it makes it clear what application the name is use= d with.

 

=93user_id=94 =96 The c= oncept you=92re describing is almost universally called =93username=94.&nbs= p; User ID is typically the numeric account identifier (carried in the =93s= ub=94 claim in a JWT), and so is not the right name for this.  Compare it t= o the preferred_username claim in OpenID Connect.  Please change this = either to =93username=94 or urn:ietf:params:oauth:introspection:username.

 

=93token_type=94 =96 Wh= ile this is well-defined, the usage is fairly specific to this application.=   Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue.

 

If you give up register= ing these names in the JWT Claims registry, I=92m OK with you using short n= ames.  But if you want them to live alongside other JWT claim names, please include the urn:ietf:params:oauth:introspection: in lieu of = registration.

 

    = ;            &n= bsp;            = ;            &n= bsp;            = ;      Thank you,

    = ;            &n= bsp;            = ;            &n= bsp;            = ;      -- Mike

 

From: OAuth = [= mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, March 04, 2015 1:46 PM
To: Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspect= ion "Claims"

 

Hi Hannes, thanks for the feedback. Responses inline= .

 

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:

 

Hi Justin, Hi all,
in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provide= s
information that help make the authorization decision. This is the token introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as a way to encode information (=3Ddata model) and almost have an identical information model (the data that is being passed around).

What needs to be done?

* Use the term 'claims' in both documents.
* Use the same registry (i.e., the registry established with the JWT).
* Register the newly defined claims from the token introspection
document in the claims registry.

 

We=92ve already done this in the latest draft. Or at= least, that=92s the intent of the current text =97 the registry is referen= ced and the new claims are registered. Can you specifically point to places= where this needs to be improved upon?



Then, I have a few comments on the new claims that a= re proposed:

Here is the definition of the 'active' claim:

  active
     REQUIRED.  Boolean indicator of whether = or not the presented token
     is currently active.  The authorization = server determines whether
     and when a given token is in an active state.=

This claim is not well-defined. You need to explain what "active"= means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

 

The definition of =93active=94 is really up to the a= uthorization server, and I=92ve yet to hear from an actual implementor who= =92s confused by this definition. When you=92re the one issuing the tokens,= you know what an =93active=94 token means to you. Still, perhaps we can be even more explicit, such as:

 

 

active

  REQUIRED. Boolean indicator of whether or not= the presented token is currently active. The specifics of a token=92s acti= ve state will vary depending on the implementation of the authorization ser= ver, but generally this will indicate that a given token has been issued by this authorization server, has not been r= evoked by the resource owner, and is within its given time window of validi= ty (e.g. not expired). 

 

Also, this is one of the places where the overlap be= tween JWT and introspection claims don=92t make sense. It doesn=92t make an= y sense for a JWT to carry an =93active=94 claim at all. Why would you have= a JWT claim to be anything but active? We should register it with the JWT registry to avoid name collisions, but the= re=92s nothing in the JWT registry that says =93don=92t use this inside of = a JWT=94. Do you have any advice on how to address this?




client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

 

Whatever it wants to. If an RS can figure out someth= ing from the client_id, why not let it? The client_id is a piece of informa= tion about the context of the issuance of the token, and a common enough OA= uth value for decision making. 



I have a couple of reactions when I read the 'user_i= d' claim:
 - I believe the inclusion of a user id field in the response could lead to further confusion regarding OAuth access token usage for
authentication.

 

This isn=92t any different from having a userinfo-en= dpoint equivalent (like social graph or twitter API) and it=92s got the sam= e trouble. 




 - Since you define it as a human readable identifier I am wondering whether you want to say something about the usage. Here it seems that it might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

 

We added in =93user_id=94 to our implementation due = to developer demand =97 they wanted a username associated with the return v= alue, but to leave the =93sub=94 value the same as that defined by OpenID C= onnect. Note that this is in an environment where the username is a known quantity, and they=92re not trying to do cro= ss-domain authentication. They just want to know whose token this was so th= ey can figure out whose data to return. It=92s not used for display, but I = tried to make the definition in contrast to the machine-facing =93sub=94 value.




 - I am missing a discussion about the privacy implications of it.
While there is a privacy consideration section I am wondering what
controls the release of this sensitive information from the
authorization server to the resource server. While in some cases the two parties might belong to the same organization but in other cases that
may not necessarily be true.

 

You=92re correct, this is currently missing and I=92= ll add that in.




 - In terms of the information exchanged about the user I am curious about the usefulness of including other information as well, such as the info that is included in an id token (see
ht= tp://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this has nothing to do with the ID token concept and the information carried
within it then I would add that remark.

 

 

You could introspect an ID token if you wanted to, b= ut it=92s usually easier to just parse it yourself because it=92s self-cont= ained. The ID Token also extends JWT, so there=92s nothing stopping you fro= m returning those claims as well. However, note that the audience of the ID token is the OAuth *client* whereas the t= argeted user of the introspection endpoint is the *protected resource*. The= PR isn=92t going to see the ID Token most of the time, and the client=92s = not going to need to (or be able to) introspect its tokens most of the time, so in practice there=92s not reall= y any overlap.

 

 =97 Justin




Ciao
Hannes

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

 


--_000_4E1F6AAD24975D4BA5B1680429673943A2E79640TK5EX14MBXC292r_-- From nobody Thu Mar 5 00:39:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE691A06FD for ; Thu, 5 Mar 2015 00:39:50 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 trQLR4RLxlLd for ; Thu, 5 Mar 2015 00:39:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29BA51B2A95 for ; Thu, 5 Mar 2015 00:39:46 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Ma1pn-1YBda43uV5-00LnqG; Thu, 05 Mar 2015 09:39:44 +0100 Message-ID: <54F8164E.6040201@gmx.net> Date: Thu, 05 Mar 2015 09:39:42 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mike Jones , Justin Richer References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RaTE4HcnN0OIlSF6rMDkeAnQwbFPSF5e7" X-Provags-ID: V03:K0:GOL5ZrYzyC4irZyU4F/t2ZHFrrFIKHWF7PIGuoU9Lz0i9TT6cNQ 4f2FiZ+rxyrwR0fNJlzHJep4oHsXSmZoJokzQERph+nv0mTezZSgEJpHAihEqAtynaZrt7v zEXeisLUluwMOv/z3jVptqX3dRyJNETbuhq5cGQ7EsqWNx3CrYDqE0HsaLMVNDGmOEcdh5I miVLZWRa8cVK3+zHHODTA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 08:39:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RaTE4HcnN0OIlSF6rMDkeAnQwbFPSF5e7 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: quoted-printable Hi Mike, Hi Justin, I guess you agree with me that fundamentally the JWT and the token introspection solve the same problem, namely to provide the authorization server with information that it can use to make an authorization decision. The difference is only in the way how the message flows. Now, to the argument that developers have not yet complained about the underspecified claims/attributes is not particularly good. We tend to hear about complains years later when things go wrong and then we cannot change them anymore. Tell me for the active claim what type of checks the authorization server is supposed to do. If the authorization server and the resource server are provided by different parties then it is important to be clear about what checks each of the two parties are supposed to be doing. If the active claim aims to outsource the authorization decision from the resource server to the authorization server then that's a completely different story than just doing some basic sanity check on some of the JWT claims. Ciao Hannes On 03/05/2015 08:36 AM, Mike Jones wrote: > It sounds to me like you're making a good argument for this spec to hav= e > its own registry. Registries are easy to establish and use. > -----------------------------------------------------------------------= - > From: Justin Richer > Sent: =FD3/=FD4/=FD2015 6:43 PM > To: Mike Jones ; Hannes Tschofenig > > Cc: > Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection= > "Claims" >=20 > I'm actually fine with keeping the introspection-specific elements out > of the registry (see my note on "active" and how it doesn't fit in JWT > below), but I do not want to give up the short names. The short names > are already in production, especially "active", which is well understoo= d > and used in practice today, and has been for years[1]. Changing this > would fundamentally break all existing implementations for no good > reason. I'm slightly more OK with changing "user_id" to "username", > since that's not as widely deployed to my knowledge (other implementers= , > please pipe up if I'm mistaken), and I'm well familiar with > "preffered_username" in OIDC because I'm the one that put it in there > [2]. :) While I prefer to leave it be at this stage, I think this is a > less destructive change than "active", "scope", or "client_id" would be= =2E >=20 > For background to my stance regarding the registry: several revisions > (and years) ago, the introspection draft re-defined several fields that= > overlapped with JWT and we were asked to correlate the two. Originally,= > we simply had a pointer to re-use the JWT claims as defined, and stacke= d > our own claims on top. Later, we were asked to outright merge them, > which is what we have right now. If the WG wants to back off that last > change to the middle state -- where we re-use the JWT registry but don'= t > write to it -- I'm very happy with that result and can work that (back)= > into the next draft. >=20 > Though it does point out something strange about the standards process > that we're running into here: JWT needed a place to register bits of > metadata about a token, so it created one. This became the "JWT > registry", and now it's got hangings of being "JWT-specific". When > introspection came along with a need to talk about much the same kind o= f > information, it makes sense to re-use the existing items but also that > there would be things that are introspection-specific. >=20 > -- Justin >=20 > [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 > [2] https://bitbucket.org/openid/connect/issue/584/messages-username-cl= aim >=20 > On 3/4/2015 6:28 PM, Mike Jones wrote: >> >> I have severe concerns with this approach. It=92s not appropriate to >> register arbitrary JSON object member names as JWT claim names =96 >> especially when the JSON object member names are not even being used >> as JWT claim names. *Please do not do this*, as it would needlessly >> pollute the JWT claim name namespace with registered names that are >> application specific. >> >> =20 >> >> Secondarily, I have concerns about these names and suggestions for how= >> to address them. >> >> =20 >> >> =93active=94 =96 This claim is not presently adequately defined. And = its >> definition will of necessity be specific to the introspection >> application. Therefore, it should not be registered as a general JWT >> claim name. A name I would be comfortable with for this concept would= >> be urn:ietf:params:oauth:introspection:active, since it makes it clear= >> what application the name is used with. >> >> =20 >> >> =93user_id=94 =96 The concept you=92re describing is almost universall= y called >> =93username=94. User ID is typically the numeric account identifier >> (carried in the =93sub=94 claim in a JWT), and so is not the right nam= e >> for this. Compare it to the preferred_username claim in OpenID >> Connect. Please change this either to =93username=94 or >> urn:ietf:params:oauth:introspection:username. >> >> =20 >> >> =93token_type=94 =96 While this is well-defined, the usage is fairly >> specific to this application. Again, adding the >> urn:ietf:params:oauth:introspection: name prefix would address this is= sue. >> >> =20 >> >> If you give up registering these names in the JWT Claims registry, I=92= m >> OK with you using short names. But if you want them to live alongside= >> other JWT claim names, please include the >> urn:ietf:params:oauth:introspection: in lieu of registration. >> >> =20 >> >> Thank you,= >> >> -- Mike >> >> =20 >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Ric= her >> *Sent:* Wednesday, March 04, 2015 1:46 PM >> *To:* Hannes Tschofenig >> *Cc:* >> *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token >> Introspection "Claims" >> >> =20 >> >> Hi Hannes, thanks for the feedback. Responses inline. >> >> =20 >> >> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig >> > wro= te: >> >> =20 >> >> Hi Justin, Hi all, >> >> in OAuth we provide two ways for a resource server to make an >> authorization decision. >> >> 1) The resource server receives a self-contained token that >> contains all >> the necessary information to make a local authorization decision. = With >> the JWT we have created such a standardized information and data >> model. >> >> 2) With an access request from a client the resource server asks t= he >> authorization server for "help". The authorization server provides= >> information that help make the authorization decision. This is the= >> token >> introspection approach. >> >> I believe the two approaches need to be aligned with regard to the= >> information and the data model. Since both documents already use >> JSON as >> a way to encode information (=3Ddata model) and almost have an ide= ntical >> information model (the data that is being passed around). >> >> What needs to be done? >> >> * Use the term 'claims' in both documents. >> * Use the same registry (i.e., the registry established with the J= WT). >> * Register the newly defined claims from the token introspection >> document in the claims registry. >> >> =20 >> >> We=92ve already done this in the latest draft. Or at least, that=92s t= he >> intent of the current text =97 the registry is referenced and the new >> claims are registered. Can you specifically point to places where this= >> needs to be improved upon? >> >> >> >> Then, I have a few comments on the new claims that are proposed: >> >> Here is the definition of the 'active' claim: >> >> active >> REQUIRED. Boolean indicator of whether or not the presented toke= n >> is currently active. The authorization server determines whether= >> and when a given token is in an active state. >> >> This claim is not well-defined. You need to explain what "active" mean= s. >> It could, for example, mean that the token is not yet expired. Then, >> there is of course the question why you are not returning the 'exp' >> claim together with the 'nbf' claim. >> >> =20 >> >> The definition of =93active=94 is really up to the authorization serve= r, >> and I=92ve yet to hear from an actual implementor who=92s confused by = this >> definition. When you=92re the one issuing the tokens, you know what an= >> =93active=94 token means to you. Still, perhaps we can be even more >> explicit, such as: >> >> =20 >> >> =20 >> >> active >> >> REQUIRED. Boolean indicator of whether or not the presented >> token is currently active. The specifics of a token=92s active sta= te >> will vary depending on the implementation of the authorization >> server, but generally this will indicate that a given token has >> been issued by this authorization server, has not been revoked by >> the resource owner, and is within its given time window of >> validity (e.g. not expired).=20 >> >> =20 >> >> Also, this is one of the places where the overlap between JWT and >> introspection claims don=92t make sense. It doesn=92t make any sense f= or a >> JWT to carry an =93active=94 claim at all. Why would you have a JWT cl= aim >> to be anything but active? We should register it with the JWT registry= >> to avoid name collisions, but there=92s nothing in the JWT registry th= at >> says =93don=92t use this inside of a JWT=94. Do you have any advice on= how >> to address this? >> >> >> >> >> client_id: What is the resource server going to do with the client_id?= >> What authorization decision could it make? >> >> =20 >> >> Whatever it wants to. If an RS can figure out something from the >> client_id, why not let it? The client_id is a piece of information >> about the context of the issuance of the token, and a common enough >> OAuth value for decision making.=20 >> >> >> >> I have a couple of reactions when I read the 'user_id' claim: >> - I believe the inclusion of a user id field in the response could >> lead to further confusion regarding OAuth access token usage for >> authentication. >> >> =20 >> >> This isn=92t any different from having a userinfo-endpoint equivalent >> (like social graph or twitter API) and it=92s got the same trouble.=20 >> >> >> >> >> - Since you define it as a human readable identifier I am wondering >> whether you want to say something about the usage. Here it seems that = it >> might be used for displaying something on a webpage rather than making= >> an authorization decision but I might well be wrong. >> >> =20 >> >> We added in =93user_id=94 to our implementation due to developer deman= d =97 >> they wanted a username associated with the return value, but to leave >> the =93sub=94 value the same as that defined by OpenID Connect. Note t= hat >> this is in an environment where the username is a known quantity, and >> they=92re not trying to do cross-domain authentication. They just want= >> to know whose token this was so they can figure out whose data to >> return. It=92s not used for display, but I tried to make the definitio= n >> in contrast to the machine-facing =93sub=94 value. >> >> >> >> >> - I am missing a discussion about the privacy implications of it. >> While there is a privacy consideration section I am wondering what >> controls the release of this sensitive information from the >> authorization server to the resource server. While in some cases the t= wo >> parties might belong to the same organization but in other cases that >> may not necessarily be true. >> >> =20 >> >> You=92re correct, this is currently missing and I=92ll add that in. >> >> >> >> >> - In terms of the information exchanged about the user I am curious >> about the usefulness of including other information as well, such as t= he >> info that is included in an id token (see >> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this= >> has nothing to do with the ID token concept and the information carrie= d >> within it then I would add that remark. >> >> =20 >> >> =20 >> >> You could introspect an ID token if you wanted to, but it=92s usually >> easier to just parse it yourself because it=92s self-contained. The ID= >> Token also extends JWT, so there=92s nothing stopping you from returni= ng >> those claims as well. However, note that the audience of the ID token >> is the OAuth *client* whereas the targeted user of the introspection >> endpoint is the *protected resource*. The PR isn=92t going to see the = ID >> Token most of the time, and the client=92s not going to need to (or be= >> able to) introspect its tokens most of the time, so in practice >> there=92s not really any overlap. >> >> =20 >> >> =97 Justin >> >> >> >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> =20 >> >=20 --RaTE4HcnN0OIlSF6rMDkeAnQwbFPSF5e7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+BZOAAoJEGhJURNOOiAtHNgH/2i81g/z4uicBxNueIzrGjVv tddcSYzAsBsLeGQMFPiZm3xnImPbf4HyaVyJ0MVhRKWUZmGJ3eDPHscCEPKl4CzR aBF01Hy173VgBEa5g8aGxzF47tUUBXomzG45RONFDfJEdoV+6uvmz1ftiDl2cQay FsYB5o28w8Ohjnbyacx5q8eKBFUQVCisxWuSbjyRk32df7rojO5PdscCBC5AkMbf TgqdTO6DjwXfp6w/zfIoDHCMnsU8Bh3S11uD4B0N71BIDJZJ8+68c397rOWCAWp4 U/0lTEwXY+l6E6gavEVuvDUdv2I8FBH73N6yu1FrzgE30MMzeACU7Ck2W8T67No= =HBVv -----END PGP SIGNATURE----- --RaTE4HcnN0OIlSF6rMDkeAnQwbFPSF5e7-- From nobody Thu Mar 5 00:51:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC8C1B2ABD; Thu, 5 Mar 2015 00:51:11 -0800 (PST) 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] autolearn=ham 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 nkMegwTXGBTe; Thu, 5 Mar 2015 00:51:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2281A19F0; Thu, 5 Mar 2015 00:51:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305085110.7062.81134.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 00:51:10 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 08:51:11 -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 Working Group of the IETF. Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution Authors : John Bradley Phil Hunt Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-pop-key-distribution-01.txt Pages : 18 Date : 2015-03-05 Abstract: RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. This document describes how the client obtains this keying material from the authorization server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 5 00:59:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14431B2AE4 for ; Thu, 5 Mar 2015 00:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_RP_RNBL=1.31, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 2XTY6M0iyuQb for ; Thu, 5 Mar 2015 00:59:10 -0800 (PST) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D421B2AE1 for ; Thu, 5 Mar 2015 00:59:10 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MGj8j-1YGXSU24LR-00DVTJ for ; Thu, 05 Mar 2015 09:59:07 +0100 Message-ID: <54F81ADA.3000203@gmx.net> Date: Thu, 05 Mar 2015 09:59:06 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lgdF91fvHiMHRqmwmUkMVI6t1p5KTjOpI" X-Provags-ID: V03:K0:OiNoCtSs4UdjHlgnC8lj8nKndi2FEQJ9XSi+iCp51PTs4vmfLpN 0mo4kzEaTebG6AQBS8jw0QYdwTL6o6z/8xtkDlFq3AcO64y5ouQsCxSROAvXQVdE4LiWnIy 8DrYzcQQvyUFCdcGBklz7lIJ2FNdWASelrgq5dikEPBUZFQGyBJzwKtddY1VQpzZJoQDji8 hZpkjvGlO3OI1kDosiKFA== X-UI-Out-Filterresults: junk:10; Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 08:59:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lgdF91fvHiMHRqmwmUkMVI6t1p5KTjOpI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I refreshed the PoP key distribution document. No changes to the content of the document. The document contains two questions, namely QUESTION: A benefit of asymmetric cryptography is to allow clients to request a PoP token for use with multiple resource servers. The downside of that approach is linkability since different resource servers will be able to link individual requests to the same client. (The same is true if the a single public key is linked with PoP tokens used with different resource servers.) Nevertheless, to support the functionality the audience parameter could carry an array of values. Is this desirable? Hannes: My view is that we do not want to introduce likability into OAuth via the use of these keys. As such, different keys for different origins. QUESTION: Should we register the token_type and alg parameters for use with the dynamic client registration protocol? Hannes: I believe we should register these two parameters into the dynamic client registration protocol since that allows us to configure the values for the client rather than exchanging them with every message.= Feedback appreciated before the submission deadline. Ciao Hannes --lgdF91fvHiMHRqmwmUkMVI6t1p5KTjOpI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+BraAAoJEGhJURNOOiAt3gUH/RIAb0ulUnbkWmibsFdAwZyz tsntXUMeM6zPtT+cU/gUkG1xy9EBSOs2HMh04UHHAPCBL0c+Vid2EugvJv2PH11i vD5ZK9526qE/eH4m8dxwcbf7wsRM39CtW0AEW9rgsfXxQPCB1Avfx7nKyZlKPiOo RhCuz18soajgYFFy+0k+PTpcD8yMYw7v4TG0yH6BEcDr9uWDLFbCpou8B/3Mt1xI AitpSQd85insRSRlmYSKXid0xZrPsiek8XZKw82FavUmx2m1Lu5ynJewDtVIPm4j WCNVGxP2LbGlwbBsSbHkaVUvEfOdzv8HBUoq/nFnTwN8vLINl1MneKWmX8CyC0c= =xFCy -----END PGP SIGNATURE----- --lgdF91fvHiMHRqmwmUkMVI6t1p5KTjOpI-- From nobody Thu Mar 5 01:28:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D821B2B62 for ; Thu, 5 Mar 2015 01:28:01 -0800 (PST) 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 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 0kLDnxxjqegd for ; Thu, 5 Mar 2015 01:28:00 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (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 9FEE61B2B5B for ; Thu, 5 Mar 2015 01:27:59 -0800 (PST) Received: by wevl61 with SMTP id l61so14721075wev.0 for ; Thu, 05 Mar 2015 01:27:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ZBgaIqe/Ljui6SXMYC/RfqAl5G+lBwjFv1s8oTMiVyE=; b=DEeWuh6dZP7c2nI3oDtnYLgSo+iJ8uB5xj9AbNbjaEfzksohr7aoF7H7fmgOtASe5M yqCyitztvdnOoyl0ThHlt/+MqW/3tdaBytEftv9M7LYULaVRV85os43TG92dY4xHGMYa +Sf0+kwV5C/X81n2o+ML9TJTPjXAqpahMQHwWymCLFZeOwH1U2FOOh934dpV3YEBbvJt WvGDLM5f7P4EEvvJcnh8URCpBVg1D+U7GGwAfY7/PqThcpqcnMLloGGoG5eAvT/kcHg6 MphQOMPE0dE+GYhYqljX+dneUeRFrjs2OKfqHNWL5AO/uzCpHtU2xJrD2KqtwAb7I6Ec PZOg== X-Gm-Message-State: ALoCoQn9icr7A18JXrfongwJXoPCEF0GYp+jKjw/5bHuL0grGFwx7RIhp/sCxYpHDOiGo8ELLJ08 X-Received: by 10.194.186.236 with SMTP id fn12mr16753200wjc.51.1425547678281; Thu, 05 Mar 2015 01:27:58 -0800 (PST) Received: from [10.6.0.209] ([95.211.146.166]) by mx.google.com with ESMTPSA id hj10sm9611642wjc.48.2015.03.05.01.27.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 01:27:57 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E7810368-0259-45BC-BD95-818B0CED197F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <54F81ADA.3000203@gmx.net> Date: Thu, 5 Mar 2015 10:27:33 +0100 Message-Id: <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> References: <54F81ADA.3000203@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 09:28:01 -0000 --Apple-Mail=_E7810368-0259-45BC-BD95-818B0CED197F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii inline > On Mar 5, 2015, at 9:59 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I refreshed the PoP key distribution document. No changes to the > content of the document. >=20 > The document contains two questions, namely >=20 > QUESTION: A benefit of asymmetric cryptography is to allow clients to > request a PoP token for use with multiple resource servers. The > downside of that approach is linkability since different resource > servers will be able to link individual requests to the same client. > (The same is true if the a single public key is linked with PoP > tokens used with different resource servers.) Nevertheless, to > support the functionality the audience parameter could carry an = array > of values. Is this desirable? >=20 >=20 > Hannes: My view is that we do not want to introduce likability into > OAuth via the use of these keys. As such, different keys for different > origins. >=20 >=20 John: Having an array increases complexity and decreases privacy by = allowing RS to link. Audiance should be a single value. That requires separate keys for = symmetric, or asymmetric keys provisioned by the AS. For asymmetric keys provisioned by the client it would be up to the = client to decide if using the same key for multiple RS makes sense. =20 It might be that there is a single key provisioned by a MSM in the tpm = that they want to use for all the connections as that is the most = secure, and are not concerned with correlation as all the RS are = internal to a single enterprise. > QUESTION: Should we register the token_type and alg parameters for use > with the dynamic client registration protocol? >=20 > Hannes: I believe we should register these two parameters into the > dynamic client registration protocol since that allows us to configure > the values for the client rather than exchanging them with every = message. >=20 John: Yes I had assumed that that was a no brainer. The other question on registering is if we should allow the client to = preregister a public key as well. In some situations the client may want to always use the same key and = making them push it each time is a waste of bandwidth. John B. > Feedback appreciated before the submission deadline. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_E7810368-0259-45BC-BD95-818B0CED197F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMDUwOTI3MzNaMCMGCSqGSIb3DQEJBDEWBBTdEwH0vXy+niA9gyWuhAMr JZDFIDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAIfmguP7krmtyvNj0P/RsUNbGfu6QOompLGiJUEQ+nybR4+0EW7nZw dq7AnkEGkx4diYKUORyrKZv7iba9E9WRNmuCyKoAqVIZfh6PMiGSi2/cjmfhpi3OBzr/VhcD1Mx5 NaUljOycRKVvlZ48rVI+jfGKZIKa9zKIkrYvjym+uz9D0Rxz6talEXl4TslB+yUjQBUHhi/xmHkA Ixzve8z52H2hzqnv+UDV82yhcXTrwIULOhobK69lFUq8yF9Am/on94HugvDKZahdEuW7jMOkvmL1 cd/tIR9ReT9EfC/gQDGKHP3ebCEmhn60BLouD7xBfUdX9OVu7VROBZG4HzoVAAAAAAAA --Apple-Mail=_E7810368-0259-45BC-BD95-818B0CED197F-- From nobody Thu Mar 5 03:34:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0938C1A1AC1 for ; Thu, 5 Mar 2015 03:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_RP_RNBL=1.31, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 KetNyc1ReS2J for ; Thu, 5 Mar 2015 03:34:16 -0800 (PST) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.42]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594861A8886 for ; Thu, 5 Mar 2015 03:34:15 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LmNHK-1XuyIw3rNq-00ZtDF; Thu, 05 Mar 2015 12:34:13 +0100 Message-ID: <54F83F32.3040305@gmx.net> Date: Thu, 05 Mar 2015 12:34:10 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Bradley References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> In-Reply-To: <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bChUKl3f4GBmqetdvowAcvw2npP8FPdQb" X-Provags-ID: V03:K0:XdXvw6FQ6Q9D/M6dELOB1XOSLiXIU5Yqnmn9huzFbYSYYP6hDIC aIjInXVy/tUrq+LMHLvcVG5A/afyYtDYgdS+DjvlSBGtnt/GCm/OCabkWbiGw7N/vrLzopf 4O+euzYOr1fQu+nSAEvjOOhR70Q9cUPF/cCg77GWq8QC/39T1wAI8tPqCURbe1gjuANsqkh 1QXYQUn+ox4NOTfKioKog== X-UI-Out-Filterresults: junk:10; Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 11:34:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bChUKl3f4GBmqetdvowAcvw2npP8FPdQb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi John, On 03/05/2015 10:27 AM, John Bradley wrote: > inline >> On Mar 5, 2015, at 9:59 AM, Hannes Tschofenig wrote: >> >> Hi all, >> >> I refreshed the PoP key distribution document. No changes to the >> content of the document. >> >> The document contains two questions, namely >> >> QUESTION: A benefit of asymmetric cryptography is to allow clients to >> request a PoP token for use with multiple resource servers. The >> downside of that approach is linkability since different resource >> servers will be able to link individual requests to the same client.= >> (The same is true if the a single public key is linked with PoP >> tokens used with different resource servers.) Nevertheless, to >> support the functionality the audience parameter could carry an arra= y >> of values. Is this desirable? >> >> >> Hannes: My view is that we do not want to introduce likability into >> OAuth via the use of these keys. As such, different keys for different= >> origins. >> >> > John: Having an array increases complexity and decreases privacy by al= lowing RS to link. >=20 > Audiance should be a single value. That requires separate keys for sym= metric, or asymmetric keys provisioned by the AS. >=20 > For asymmetric keys provisioned by the client it would be up to the cli= ent to decide if using the same key for multiple RS makes sense. =20 >=20 > It might be that there is a single key provisioned by a MSM in the tpm = that they want to use for all the connections as that is the most secure,= and are not concerned with correlation as all the RS are internal to a s= ingle enterprise. >=20 OK. >=20 >=20 >> QUESTION: Should we register the token_type and alg parameters for use= >> with the dynamic client registration protocol? >> >> Hannes: I believe we should register these two parameters into the >> dynamic client registration protocol since that allows us to configure= >> the values for the client rather than exchanging them with every messa= ge. >> > John: Yes I had assumed that that was a no brainer. > The other question on registering is if we should allow the client to p= reregister a public key as well. > In some situations the client may want to always use the same key and m= aking them push it each time is a waste of bandwidth. The dynamic client registration already supports the feature of uploading a public key to the authorization server and hence the missing feature to support that case is to allow the client to refer to that key somehow. I assume that the public key uploaded by the dynamic client registration protocol is referenced using a URI. The question is just what that URI would be. Unfortunately, the Dynamic Client Registration spec is silent about how to reference the public key uploaded via the jwks parameter. Did we just found a bug in the spec? Ciao Hannes >=20 > John B. >> Feedback appreciated before the submission deadline. >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --bChUKl3f4GBmqetdvowAcvw2npP8FPdQb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+D8yAAoJEGhJURNOOiAttt0H/RFg6RQwaJuTuFquMk+thA4z HrhfwnXM55SwkAART5IrIf4QXdSeGMFYewAGjbCYy1dxE+SgoDFQoYjfbSy7zbcr +c1rqnXYPrn5nZ7miTsVvI2BspnnkU0O2uAcSx0yLQOh7ydTi3CcDzFwkt/Vwfh2 1oph0bfGK3m7bz3cv+HbQAegEy5NJRxiqThlkuneLpBn6CFXkxbyR5F6jPa7lAys kbx3jOKrYeEWr4cuAc5TuCQeUh6NsvU4+LJmIU/MG286SCPBNXHzk5PME9d0ZGs3 1hVsbO+SkI51RoBl00g3bdckgzsOsbabfDrEy1ta17XWkYeL5c5u1U+Fi3SQ5hM= =IAvN -----END PGP SIGNATURE----- --bChUKl3f4GBmqetdvowAcvw2npP8FPdQb-- From nobody Thu Mar 5 03:38:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D301A1B17 for ; Thu, 5 Mar 2015 03:38:01 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZfAcE4KSmfuP for ; Thu, 5 Mar 2015 03:38:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8D41A872F for ; Thu, 5 Mar 2015 03:37:58 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MhRUQ-1Y7zEc2lAw-00MdIw for ; Thu, 05 Mar 2015 12:37:56 +0100 Message-ID: <54F84013.9090004@gmx.net> Date: Thu, 05 Mar 2015 12:37:55 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="S4M1cbldI6pT1QjK9dMX05jroK4q8RRgC" X-Provags-ID: V03:K0:N4Rb8GrvvZNkNmVYvfMEuGtAa1yzHtBYuF/pcCgXCqIx+vvYvwp zNzADNUa8SBauUrfnSwtl81AQQHvfCGQdJwUlop+VA8cQJv9xNgkDj481GZyEN+MTXxwu6n HAXRCNI8xd+PD8p2Q93okVVLYQtPc4oa6qsVw4+j81StiVZiovWD6SZPsnacbQwh2xcjcTg I9H9kmiI0h30mWdonySAg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Dynamic Client Registration & Key Naming of JWKS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 11:38:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S4M1cbldI6pT1QjK9dMX05jroK4q8RRgC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, Hi all, In context of the draft-ietf-oauth-pop-key-distribution-01 update we just ran into a question regarding key naming. The Dynamic Client Registration Protocol defines these two parameters that allow a client to upload a public key to the authorization server: jwks_uri URL referencing the client's JSON Web Key Set [JWK] document, which contains the client's public keys. The value of this field MUST point to a valid JWK Set document. These keys can be used by higher level protocols that use signing or encryption. For instance, these keys might be used by some applications for validating signed requests made to the token endpoint when using JWTs for client authentication [OAuth.JWT]. Use of this parameter is preferred over the "jwks" parameter, as it allows for easier key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response. jwks Client's JSON Web Key Set [JWK] document value, which contains the client's public keys. The value of this field MUST be a JSON object containing a valid JWK Set. These keys can be used by higher level protocols that use signing or encryption. This parameter is intended to be used by clients that cannot use the "jwks_uri" parameter, such as native clients that cannot host public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response. Now, the question is how these keys are actually referenced? What do I need to indicate to select a specific key when I want to use these keys. Ciao Hannes --S4M1cbldI6pT1QjK9dMX05jroK4q8RRgC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+EATAAoJEGhJURNOOiAtd9AH/00k35NyGT8bNoCZ2XHRDLC6 dVfoIBmmps9rwmC4U6JMGhpKQxcHU/EfPxr9zret4TdlUH2g6DxWSMXmHVRkbRiS yVVwtKfRsT0NyXPR7mXbaYY0u9AgCAe13mD+eeXY5KUfG+muQhN4OmNMo1ubfUcK 0h1XtxJlcsG+H4XKD2tny4nyoOr1d3HRVGKHTe0tzqv5203qjtNWNq/ItXbSsoAS oNCXC7kN7S0kygyL5+FSJMbZIsqJnMhgp+3ffsqEHnmygjbmB3L9Rp+Dz+7eI4q2 U0lmjBMRsk+CiUnQxedQ0x8YihaYsgIw+YzhMULqjAPnKUCh2LlxWrfKNVKWBlA= =gNiU -----END PGP SIGNATURE----- --S4M1cbldI6pT1QjK9dMX05jroK4q8RRgC-- From nobody Thu Mar 5 03:51:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382971B2C35 for ; Thu, 5 Mar 2015 03:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yYiG2RtC57hz for ; Thu, 5 Mar 2015 03:51:52 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049691B29B9 for ; Thu, 5 Mar 2015 03:51:45 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-e9-54f84350c308 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id C3.53.21729.05348F45; Thu, 5 Mar 2015 06:51:44 -0500 (EST) 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 t25BphWf001877; Thu, 5 Mar 2015 06:51:44 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t25Bpgoq015879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 06:51:43 -0500 Message-ID: <54F84347.5040705@mit.edu> Date: Thu, 05 Mar 2015 06:51:35 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <54F84013.9090004@gmx.net> In-Reply-To: <54F84013.9090004@gmx.net> Content-Type: multipart/alternative; boundary="------------080400060206090400070409" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hTV1g1w/hFi8P+gpsXSnfdYLU6+fcXm wOSxeNN+No8lS34yBTBFcdmkpOZklqUW6dslcGX8/HeEvWCtRcXW9vWsDYwNOl2MnBwSAiYS V5q/skLYYhIX7q1n62Lk4hASWMwkcfvUBShnA6PEu8Or2CGcW0wShx+3MnUxcnDwCqhJTOzJ B+lmEVCVODb/NAuIzQZkT1/TwgRiiwpESfT86WYDsXkFBCVOznwCViMiECtx6e8JsM3CAh4S 93fdYQSxhYBGft46jR3E5hRQl3j5Zw5YnFkgTOL0u91MExj5ZyEZNQtJCsK2lbgzdzczhC0v sf3tHChbV2LRthXsMPHmrbOZFzCyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdK10MvNLNFLTSnd xAgKbHYX1R2MEw4pHWIU4GBU4uGdsfF7iBBrYllxZe4hRkkOJiVR3mDjHyFCfEn5KZUZicUZ 8UWlOanFhxglOJiVRHjztYByvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIc HEoSvDpOQI2CRanpqRVpmTklCGkmDk6Q4TxAw986ggwvLkjMLc5Mh8ifYlSUEufdCZIQAElk lObB9cISzytGcaBXhHl1QVbwAJMWXPcroMFMQIO1xMAGlyQipKQaGNOvqMYsjX/amuRUY5um 9Sz9yZE0+0Wu2y5ndy7c9isy5tOWAt1nmQmPmxSOBRT1KKhu8WqKvp7d0L7Ot875vNLK9S1B 5/72TbXlXHjz+P6u5HurtiQWCDueuHBtXeK3nMXT2O8s2RPBcWplY1lBeNyNF/nRclbL26oU jugVdX04pagT+vHQFCWW4oxEQy3mouJEAJTQzy8XAwAA Archived-At: Subject: Re: [OAUTH-WG] Dynamic Client Registration & Key Naming of JWKS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 11:51:55 -0000 This is a multi-part message in MIME format. --------------080400060206090400070409 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit If you're using them for the token endpoint, you set your token_endpoint_authorization_method to a method that supports it (which we don't define in OAuth but other protocols and profiles do). Then you'll usually reference them using the 'kid' field defined in JWK, or you might just use the only key that's been registered (it's very common for a client to have only one key), or you might pass the JWK URI directly (in the "jku" header), or several other methods. If you're using them for some other piece of interaction (of which there are several defined and in the wild already), then the same rubric applies. This is all discussed in the JOSE documents, such as this section in JWS: https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-D What we're providing is a hook for higher level protocols, not a determination of how exactly to use it. All of these uses will reference back to the client performing the action, which can be correlated to the JWK set referenced in the registration below. -- Justin On 3/5/2015 6:37 AM, Hannes Tschofenig wrote: > Hi Justin, Hi all, > > In context of the draft-ietf-oauth-pop-key-distribution-01 update we > just ran into a question regarding key naming. > > The Dynamic Client Registration Protocol defines these two parameters > that allow a client to upload a public key to the authorization server: > > jwks_uri > URL referencing the client's JSON Web Key Set [JWK] document, > which contains the client's public keys. The value of this field > MUST point to a valid JWK Set document. These keys can be used by > higher level protocols that use signing or encryption. For > instance, these keys might be used by some applications for > validating signed requests made to the token endpoint when using > JWTs for client authentication [OAuth.JWT]. Use of this parameter > is preferred over the "jwks" parameter, as it allows for easier > key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both > be present in the same request or response. > jwks > Client's JSON Web Key Set [JWK] document value, which contains the > client's public keys. The value of this field MUST be a JSON > object containing a valid JWK Set. These keys can be used by > higher level protocols that use signing or encryption. This > parameter is intended to be used by clients that cannot use the > "jwks_uri" parameter, such as native clients that cannot host > public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both > be present in the same request or response. > > Now, the question is how these keys are actually referenced? What do I > need to indicate to select a specific key when I want to use these keys. > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080400060206090400070409 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit If you're using them for the token endpoint, you set your token_endpoint_authorization_method to a method that supports it (which we don't define in OAuth but other protocols and profiles do). Then you'll usually reference them using the 'kid' field defined in JWK, or you might just use the only key that's been registered (it's very common for a client  to have only one key), or you might pass the JWK URI directly (in the "jku" header), or several other methods. If you're using them for some other piece of interaction (of which there are several defined and in the wild already), then the same rubric applies. This is all discussed in the JOSE documents, such as this section in JWS:

https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-D

What we're providing is a hook for higher level protocols, not a determination of how exactly to use it. All of these uses will reference back to the client performing the action, which can be correlated to the JWK set referenced in the registration below.

 -- Justin

On 3/5/2015 6:37 AM, Hannes Tschofenig wrote:
Hi Justin, Hi all,

In context of the draft-ietf-oauth-pop-key-distribution-01 update we
just ran into a question regarding key naming.

The Dynamic Client Registration Protocol defines these two parameters
that allow a client to upload a public key to the authorization server:

   jwks_uri
      URL referencing the client's JSON Web Key Set [JWK] document,
      which contains the client's public keys.  The value of this field
      MUST point to a valid JWK Set document.  These keys can be used by
      higher level protocols that use signing or encryption.  For
      instance, these keys might be used by some applications for
      validating signed requests made to the token endpoint when using
      JWTs for client authentication [OAuth.JWT].  Use of this parameter
      is preferred over the "jwks" parameter, as it allows for easier
      key rotation.  The "jwks_uri" and "jwks" parameters MUST NOT both
      be present in the same request or response.
   jwks
      Client's JSON Web Key Set [JWK] document value, which contains the
      client's public keys.  The value of this field MUST be a JSON
      object containing a valid JWK Set. These keys can be used by
      higher level protocols that use signing or encryption.  This
      parameter is intended to be used by clients that cannot use the
      "jwks_uri" parameter, such as native clients that cannot host
      public URLs.  The "jwks_uri" and "jwks" parameters MUST NOT both
      be present in the same request or response.

Now, the question is how these keys are actually referenced? What do I
need to indicate to select a specific key when I want to use these keys.

Ciao
Hannes




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

--------------080400060206090400070409-- From nobody Thu Mar 5 03:54:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701B01B2C36 for ; Thu, 5 Mar 2015 03:54:56 -0800 (PST) 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 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 zrno0TGZEfMz for ; Thu, 5 Mar 2015 03:54:54 -0800 (PST) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (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 E6B451A1B4C for ; Thu, 5 Mar 2015 03:54:53 -0800 (PST) Received: by wevl61 with SMTP id l61so15480204wev.0 for ; Thu, 05 Mar 2015 03:54:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=MXW0lPAr0zOYi9Kuk5Z2eDFGiJyGxLfNxcXR5MHnknw=; b=Ik8xGevfNgeYn9Tssg6J1rNY+BaDchnYOBVSpCUZlo/A0qWGJJSoUZL3/BOd0wrBLp bJDBgWmwwqVfRjPWu1C/FPE/8BcxqPMhlt9ay1N0snFnRherR4iFYcv84tZb0OvVEyJX 278dOkuFo7eI60sIsUCJAI3ihsBcJSJbjddj+SI4am/wF6YGk6+3rCyVyS7KaL3cOqAI 7BUHHRc4eQK1ZkCNj4he9o3LYFrB7JRM66RT0GaSHHi6OTp5/7ZqsDfsYZNrhWOF3RkS PLezlXax3qkRnBXGBhdhFeLTaVhY4j8BETLLPMhB3XPHM342rBvfwJ94NzKIVnKIBZmc UxpA== X-Gm-Message-State: ALoCoQm6Ekjtnp1i8JsO7c9ninDpnpyiS9rqj5Ze/Q4y8cTthxfIzFrffVD8yHpzErPeLKhEr32y X-Received: by 10.194.62.167 with SMTP id z7mr18075499wjr.106.1425556492708; Thu, 05 Mar 2015 03:54:52 -0800 (PST) Received: from [10.6.0.209] ([95.211.146.166]) by mx.google.com with ESMTPSA id bd1sm8656196wib.13.2015.03.05.03.54.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 03:54:51 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_4510CBE6-ED69-46F3-B22F-C97E758CEFC9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <54F83F32.3040305@gmx.net> Date: Thu, 5 Mar 2015 12:54:39 +0100 Message-Id: References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 11:54:56 -0000 --Apple-Mail=_4510CBE6-ED69-46F3-B22F-C97E758CEFC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For signing authentication requests you include the keyid in the JWT, = and the AS looks in the JWKS to find the correct key if there is more = than one. I don't think that is a problem What we probably need to do is pass a keyid in the request if there is = more than one signing key registered for the client. John B. > On Mar 5, 2015, at 12:34 PM, Hannes Tschofenig = wrote: >=20 > Hi John, >=20 >=20 > On 03/05/2015 10:27 AM, John Bradley wrote: >> inline >>> On Mar 5, 2015, at 9:59 AM, Hannes Tschofenig = wrote: >>>=20 >>> Hi all, >>>=20 >>> I refreshed the PoP key distribution document. No changes to the >>> content of the document. >>>=20 >>> The document contains two questions, namely >>>=20 >>> QUESTION: A benefit of asymmetric cryptography is to allow clients = to >>> request a PoP token for use with multiple resource servers. The >>> downside of that approach is linkability since different resource >>> servers will be able to link individual requests to the same = client. >>> (The same is true if the a single public key is linked with PoP >>> tokens used with different resource servers.) Nevertheless, to >>> support the functionality the audience parameter could carry an = array >>> of values. Is this desirable? >>>=20 >>>=20 >>> Hannes: My view is that we do not want to introduce likability into >>> OAuth via the use of these keys. As such, different keys for = different >>> origins. >>>=20 >>>=20 >> John: Having an array increases complexity and decreases privacy by = allowing RS to link. >>=20 >> Audiance should be a single value. That requires separate keys for = symmetric, or asymmetric keys provisioned by the AS. >>=20 >> For asymmetric keys provisioned by the client it would be up to the = client to decide if using the same key for multiple RS makes sense. =20 >>=20 >> It might be that there is a single key provisioned by a MSM in the = tpm that they want to use for all the connections as that is the most = secure, and are not concerned with correlation as all the RS are = internal to a single enterprise. >>=20 >=20 > OK. >=20 >>=20 >>=20 >>> QUESTION: Should we register the token_type and alg parameters for = use >>> with the dynamic client registration protocol? >>>=20 >>> Hannes: I believe we should register these two parameters into the >>> dynamic client registration protocol since that allows us to = configure >>> the values for the client rather than exchanging them with every = message. >>>=20 >> John: Yes I had assumed that that was a no brainer. >> The other question on registering is if we should allow the client to = preregister a public key as well. >> In some situations the client may want to always use the same key and = making them push it each time is a waste of bandwidth. > The dynamic client registration already supports the feature of > uploading a public key to the authorization server and hence the = missing > feature to support that case is to allow the client to refer to that = key > somehow. I assume that the public key uploaded by the dynamic client > registration protocol is referenced using a URI. The question is just > what that URI would be. >=20 > Unfortunately, the Dynamic Client Registration spec is silent about = how > to reference the public key uploaded via the jwks parameter. Did we = just > found a bug in the spec? >=20 > Ciao > Hannes >=20 >=20 >>=20 >> John B. >>> Feedback appreciated before the submission deadline. >>>=20 >>> Ciao >>> Hannes >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4510CBE6-ED69-46F3-B22F-C97E758CEFC9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMDUxMTU0NDBaMCMGCSqGSIb3DQEJBDEWBBStWjCbYpIZPK4GujE4LcT6 TW6qizCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA3kXbA6GAbYV1ijTZy9awLTfBt3Z6KrbL7FZcgO0tSloPK2xEF3kQ2 cg+i+JTsSU2EJop82QMnXB9KaBi7ZotkFoqjx5TIHPpfplRCzutPSOeuAyiFZpqcMt5uuAI9usVz NfcMD6+sb2vLq2K1dwI4RxMVR4TxkDTxE0+bdUGse8zEoU1uZ9TL95sKDy5+pgNiYNgxQAMvs9OQ 5QWEXDmtHBcpRacDrAVG+OsD/Kp2MTBCLRpbudYxlT4eAkilUxNdTiRX5wxMltxqfUVy+YsJqiGs LNEh9nin2zGeOXCf9dN4To4PSYkRGkhVelVSu0gxaGe8dUwxTKIbAkApD/FfAAAAAAAA --Apple-Mail=_4510CBE6-ED69-46F3-B22F-C97E758CEFC9-- From nobody Thu Mar 5 04:03:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B5A1B29B8 for ; Thu, 5 Mar 2015 04:02:59 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 P9Kyz82FPMz3 for ; Thu, 5 Mar 2015 04:02:57 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (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 D166C1A1AA2 for ; Thu, 5 Mar 2015 04:02:56 -0800 (PST) Received: by wghb13 with SMTP id b13so52914782wgh.0 for ; Thu, 05 Mar 2015 04:02:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ggSE2PlJytO33oAURSdGusfhnirH7Du+cI0JK82vT/M=; b=ea8w9CEqUm7fLFXBJ/xA5TCQn5AzPVUuL1A5g6OTrrLkcuMJfT2aWkP5OvWdCYAKaS T5UlzhgI2KO7sC8TiKDuDfvmNprRfOf1f15p4rWMM63Sxh/InHImC5X99TSxPAPDgNWy j1P/UmQVGx6MbYEk/Z11kutEdgXNt1bkMMlLzulsVv2PMCLz0TDNzeWsDvK5cm3GF5zd dMRu5fO6jfFlro59MxWlkJivaHRjrDTwtzVnJxugPYz9eC030iEw1XZzyVq1+B52nd+Z EFnI2OLqBQ16ebNiisCnzS1Uw3TPl9RsTEx+RI5dtte+BHUgGnusH+1aQjfnUBMgKYLl 123w== X-Gm-Message-State: ALoCoQmS7K/FAQZjK2c1EOVuUNWIHWPKBP1kK/XSsqEfyijuk6jHVLGVqUsy3214cjfP57qxw7vl X-Received: by 10.194.62.52 with SMTP id v20mr17597856wjr.137.1425556975592; Thu, 05 Mar 2015 04:02:55 -0800 (PST) Received: from [10.6.0.209] ([95.211.146.166]) by mx.google.com with ESMTPSA id j7sm11357909wix.4.2015.03.05.04.02.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 04:02:54 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_33C3D253-32E9-4384-8B18-8312BC709652"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <54F84347.5040705@mit.edu> Date: Thu, 5 Mar 2015 13:02:32 +0100 Message-Id: <431F49E0-2356-4EF3-A22C-33B81EAB5301@ve7jtb.com> References: <54F84013.9090004@gmx.net> <54F84347.5040705@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration & Key Naming of JWKS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:03:00 -0000 --Apple-Mail=_33C3D253-32E9-4384-8B18-8312BC709652 Content-Type: multipart/alternative; boundary="Apple-Mail=_F26F2908-09A5-4538-BA6A-C2A4ED9CFB5A" --Apple-Mail=_F26F2908-09A5-4538-BA6A-C2A4ED9CFB5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The kid in the JWT is the most appropriate thing if the iss has = reregistered a jwks_uri. If you send a jwks_uri the AS needs to have = some trust model to match the "iss" to that jwks_uri that we haven't = described for Connect or Oauth at this point. Mostly we have been sticking to jwks that are pushed durring = registration or a jwks_uri that is pushed in registration or discovered = based on the iss in Connect discovery. Yes we need discovery for Oauth at some point. The PoP key distribution needs a parameter to pass a kid if you are not = passing the key. John B. > On Mar 5, 2015, at 12:51 PM, Justin Richer wrote: >=20 > If you're using them for the token endpoint, you set your = token_endpoint_authorization_method to a method that supports it (which = we don't define in OAuth but other protocols and profiles do). Then = you'll usually reference them using the 'kid' field defined in JWK, or = you might just use the only key that's been registered (it's very common = for a client to have only one key), or you might pass the JWK URI = directly (in the "jku" header), or several other methods. If you're = using them for some other piece of interaction (of which there are = several defined and in the wild already), then the same rubric applies. = This is all discussed in the JOSE documents, such as this section in = JWS: >=20 > = https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix= -D = >=20 > What we're providing is a hook for higher level protocols, not a = determination of how exactly to use it. All of these uses will reference = back to the client performing the action, which can be correlated to the = JWK set referenced in the registration below.=20 >=20 > -- Justin >=20 > On 3/5/2015 6:37 AM, Hannes Tschofenig wrote: >> Hi Justin, Hi all, >>=20 >> In context of the draft-ietf-oauth-pop-key-distribution-01 update we >> just ran into a question regarding key naming. >>=20 >> The Dynamic Client Registration Protocol defines these two parameters >> that allow a client to upload a public key to the authorization = server: >>=20 >> jwks_uri >> URL referencing the client's JSON Web Key Set [JWK] document, >> which contains the client's public keys. The value of this = field >> MUST point to a valid JWK Set document. These keys can be used = by >> higher level protocols that use signing or encryption. For >> instance, these keys might be used by some applications for >> validating signed requests made to the token endpoint when = using >> JWTs for client authentication [OAuth.JWT]. Use of this = parameter >> is preferred over the "jwks" parameter, as it allows for easier >> key rotation. The "jwks_uri" and "jwks" parameters MUST NOT = both >> be present in the same request or response. >> jwks >> Client's JSON Web Key Set [JWK] document value, which contains = the >> client's public keys. The value of this field MUST be a JSON >> object containing a valid JWK Set. These keys can be used by >> higher level protocols that use signing or encryption. This >> parameter is intended to be used by clients that cannot use the >> "jwks_uri" parameter, such as native clients that cannot host >> public URLs. The "jwks_uri" and "jwks" parameters MUST NOT = both >> be present in the same request or response. >>=20 >> Now, the question is how these keys are actually referenced? What do = I >> need to indicate to select a specific key when I want to use these = keys. >>=20 >> Ciao >> Hannes >>=20 >>=20 >>=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 --Apple-Mail=_F26F2908-09A5-4538-BA6A-C2A4ED9CFB5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The kid in the JWT is the most appropriate thing if the iss = has reregistered a jwks_uri.   If you send a jwks_uri the AS needs = to have some trust model to match the "iss" to that jwks_uri that we = haven't described for Connect or Oauth at this point.

Mostly we have been sticking to jwks = that are pushed durring registration or a jwks_uri that is pushed in = registration or discovered based on the iss in Connect = discovery.

Yes = we need discovery for Oauth at some point.

The PoP key distribution needs a = parameter to pass a kid if you are not passing the key.

John B.
On = Mar 5, 2015, at 12:51 PM, Justin Richer <jricher@mit.edu> = wrote:

=20 =20
If you're using them for the token endpoint, you set your token_endpoint_authorization_method to a method that supports it (which we don't define in OAuth but other protocols and profiles do). Then you'll usually reference them using the 'kid' field defined in JWK, or you might just use the only key that's been registered (it's very common for a client  to have only one = key), or you might pass the JWK URI directly (in the "jku" header), or several other methods. If you're using them for some other piece of interaction (of which there are several defined and in the wild already), then the same rubric applies. This is all discussed in the JOSE documents, such as this section in JWS:

https://tools.ietf.org/html/draft-ietf-jose-json-web-signature= -41#appendix-D

What we're providing is a hook for higher level protocols, not a determination of how exactly to use it. All of these uses will reference back to the client performing the action, which can be correlated to the JWK set referenced in the registration below.

 -- Justin

On 3/5/2015 6:37 AM, Hannes = Tschofenig wrote:
Hi Justin, Hi all,

In context of the draft-ietf-oauth-pop-key-distribution-01 update we
just ran into a question regarding key naming.

The Dynamic Client Registration Protocol defines these two parameters
that allow a client to upload a public key to the authorization server:

   jwks_uri
      URL referencing the client's JSON Web Key Set [JWK] document,
      which contains the client's public keys.  The value of this field
      MUST point to a valid JWK Set document.  These keys can be used by
      higher level protocols that use signing or encryption.  For
      instance, these keys might be used by some applications for
      validating signed requests made to the token endpoint when using
      JWTs for client authentication [OAuth.JWT].  Use of this parameter
      is preferred over the "jwks" parameter, as it allows for easier
      key rotation.  The "jwks_uri" and "jwks" parameters MUST NOT both
      be present in the same request or response.
   jwks
      Client's JSON Web Key Set [JWK] document value, which contains the
      client's public keys.  The value of this field MUST be a JSON
      object containing a valid JWK Set. These keys can be used by
      higher level protocols that use signing or encryption.  This
      parameter is intended to be used by clients that cannot use the
      "jwks_uri" parameter, such as native clients that cannot host
      public URLs.  The "jwks_uri" and "jwks" parameters MUST NOT both
      be present in the same request or response.

Now, the question is how these keys are actually referenced? What do I
need to indicate to select a specific key when I want to use these keys.

Ciao
Hannes




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

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

= --Apple-Mail=_F26F2908-09A5-4538-BA6A-C2A4ED9CFB5A-- --Apple-Mail=_33C3D253-32E9-4384-8B18-8312BC709652 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMDUxMjAyMzJaMCMGCSqGSIb3DQEJBDEWBBTHPSUw8JONlIDyT6wu9o6v khn/FTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAgZbGKiM9AlqdGwG4vk6ilsSHjbvKdLIYqFseOH8EFD9QMS9jFFz2k dlALdSTBDwT0jiLQ6rEYSNhhB9PG6PgXHNi2NtBGG7E6fA3IaDKmpPc/vJkVBuRogFYXDmQ+UK1W XBXncssjDUTKXMzRzWuGrkBymydErOYhpe0EJSao7jlcTqXg9atknwU8PEGN2x1JLdKLF7Zv5hBc 9zHUe2C/s+965cnABZYmA9/LSJV4KfttEb2SzzrAmnOPR35boy6j/Q0iak4qONuJf1BhcXdCevYy SLftQJowhMTyKfJXyoKU/beYDIqfLtPeh3HUj/DYaDBNGlwdK4+dbejDkjmNAAAAAAAA --Apple-Mail=_33C3D253-32E9-4384-8B18-8312BC709652-- From nobody Thu Mar 5 04:23:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB5D1A88F9 for ; Thu, 5 Mar 2015 04:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3yRl54zgdANn for ; Thu, 5 Mar 2015 04:23:48 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40FE1A8729 for ; Thu, 5 Mar 2015 04:23:47 -0800 (PST) X-AuditID: 1209190e-f79bb6d0000030e8-1b-54f84ad27d3e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (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 10.95.12520.2DA48F45; Thu, 5 Mar 2015 07:23:46 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t25CNj57019385; Thu, 5 Mar 2015 07:23:45 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t25CNh4H022627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 07:23:44 -0500 Message-ID: <54F84AC8.50109@mit.edu> Date: Thu, 05 Mar 2015 07:23:36 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , Mike Jones References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F8164E.6040201@gmx.net> In-Reply-To: <54F8164E.6040201@gmx.net> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT0b3k9SPEYP8EYYulO++xWuyd9onF 4uTbV2wOzB6LN+1n81iy5CeTR+uOv+wBzFFcNimpOZllqUX6dglcGZ/23WMp+Fpf8WjxHdYG xpUpXYycHBICJhJ/Xh5jgrDFJC7cW8/WxcjFISSwmEniwvU+FghnA6PEwtMdzBDOLSaJ3x2t rCAtvAIqEo1HlzGC2CwCqhLfDvWwgdhsQPb0NS1gY0UFoiR6/nSzQdQLSpyc+YQFxBYRSJE4 PO0E2BxmAXWJ3t8rwWxhgQCJFdtOgtlCAluZJCYdNQKxOYFqrpxYAnQEB1C9rcT0w9IQrfIS zVtnM09gFJyFZMMshKpZSKoWMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3E CAppTkm+HYxfDyodYhTgYFTi4f2w+XuIEGtiWXFl7iFGSQ4mJVHeYOMfIUJ8SfkplRmJxRnx RaU5qcWHGCU4mJVEePO1gHK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwc ShK8yzyBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGrwKp4S0uSMwtzkyHyJ9iVJQS5+0FSQiAJDJK 8+B6YSnnFaM40CvCvH9AqniA6Qqu+xXQYCagwVpiYINLEhFSUg2MpUZvlDR+5q9N012rkcaa lDw1Tfzbca8pr+4/cLG/c+LX+5YDRj/b9oqd6/L98e3hv09lt5LCnwfEBL5oD7d6+rrxtNye qrsFm/7/TZOu33vGtbaf19uB03VdbEfbV46fIiV1ZVGOZ17eeJg1JcD16PHNc/+XMuVFPV3s V3ko6Nfqq17HjF3XKbEUZyQaajEXFScCALQh9SMUAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:23:52 -0000 The "active" claim boils down to the AS saying "Do I think this token is any good or not?" and it's really up to the AS how it determines that. Our own implementation does a data store lookup on the token value. If it finds the token, then the token is active. If the token had been revoked, or expired, then it wouldn't have come out of the data store in the first place, and it's not active. I've seen others do the same thing. Other stateless implementations are going to probably parse the token itself and do things like check claims and signatures to see if the token's any good. Or they might decrypt the token at the AS (assuming in this example that it was encrypted using the AS's key) and dig inside the protected structure that's not available to the RS. Once it's inside that structure the AS can figure out if the token's active or not, and tell the RS. Or there might be a combination of the two where the AS parses the token and checks its signature and then uses some key field in the token to look up more information in a data store. If all that checks out then the token is active, probably. And the AS might want to do other checks, like see if this particular RS is even allowed to ask about this particular token. It is not, however, just a sanity check across other claims already embedded in the token -- you could very easily use an unstructured token. In fact, that's the world that this was first deployed in back 4-5 years ago. The important thing is that as far as the RS is concerned, the AS did *some* check on the token and came back with a thumbs up / thumbs down response. The thumbs up response can contain other information as well, such as scopes and client IDs and whatnot, which can help the RS make its authorization decision. But at its core, the "active" claim fundamentally says "is this token any good at all, according to the AS that I asked?" and the RS can make its primary authorization decision based on that. If the RS has made the decision to outsource the token validity check to the AS, then the RS either understands or doesn't care what checks the AS makes in its decision regardless of implementation or vendor. Either way, it will abide by them since that's the whole point of outsourcing that decision. And I think you're too quick to dismiss the lack of confusion on the part of developers, considering that they are in fact the target audience of specifications like this. If we're not writing these documents for developers, who are we writing them for? -- Justin On 3/5/2015 3:39 AM, Hannes Tschofenig wrote: > Hi Mike, Hi Justin, > > I guess you agree with me that fundamentally the JWT and the token > introspection solve the same problem, namely to provide the > authorization server with information that it can use to make an > authorization decision. The difference is only in the way how the > message flows. > > Now, to the argument that developers have not yet complained about the > underspecified claims/attributes is not particularly good. We tend to > hear about complains years later when things go wrong and then we cannot > change them anymore. > > Tell me for the active claim what type of checks the authorization > server is supposed to do. > > If the authorization server and the resource server are provided by > different parties then it is important to be clear about what checks > each of the two parties are supposed to be doing. If the active claim > aims to outsource the authorization decision from the resource server to > the authorization server then that's a completely different story than > just doing some basic sanity check on some of the JWT claims. > > Ciao > Hannes > > > On 03/05/2015 08:36 AM, Mike Jones wrote: >> It sounds to me like you're making a good argument for this spec to have >> its own registry. Registries are easy to establish and use. >> ------------------------------------------------------------------------ >> From: Justin Richer >> Sent: ý3/ý4/ý2015 6:43 PM >> To: Mike Jones ; Hannes Tschofenig >> >> Cc: >> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection >> "Claims" >> >> I'm actually fine with keeping the introspection-specific elements out >> of the registry (see my note on "active" and how it doesn't fit in JWT >> below), but I do not want to give up the short names. The short names >> are already in production, especially "active", which is well understood >> and used in practice today, and has been for years[1]. Changing this >> would fundamentally break all existing implementations for no good >> reason. I'm slightly more OK with changing "user_id" to "username", >> since that's not as widely deployed to my knowledge (other implementers, >> please pipe up if I'm mistaken), and I'm well familiar with >> "preffered_username" in OIDC because I'm the one that put it in there >> [2]. :) While I prefer to leave it be at this stage, I think this is a >> less destructive change than "active", "scope", or "client_id" would be. >> >> For background to my stance regarding the registry: several revisions >> (and years) ago, the introspection draft re-defined several fields that >> overlapped with JWT and we were asked to correlate the two. Originally, >> we simply had a pointer to re-use the JWT claims as defined, and stacked >> our own claims on top. Later, we were asked to outright merge them, >> which is what we have right now. If the WG wants to back off that last >> change to the middle state -- where we re-use the JWT registry but don't >> write to it -- I'm very happy with that result and can work that (back) >> into the next draft. >> >> Though it does point out something strange about the standards process >> that we're running into here: JWT needed a place to register bits of >> metadata about a token, so it created one. This became the "JWT >> registry", and now it's got hangings of being "JWT-specific". When >> introspection came along with a need to talk about much the same kind of >> information, it makes sense to re-use the existing items but also that >> there would be things that are introspection-specific. >> >> -- Justin >> >> [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 >> [2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim >> >> On 3/4/2015 6:28 PM, Mike Jones wrote: >>> I have severe concerns with this approach. It’s not appropriate to >>> register arbitrary JSON object member names as JWT claim names – >>> especially when the JSON object member names are not even being used >>> as JWT claim names. *Please do not do this*, as it would needlessly >>> pollute the JWT claim name namespace with registered names that are >>> application specific. >>> >>> >>> >>> Secondarily, I have concerns about these names and suggestions for how >>> to address them. >>> >>> >>> >>> “active” – This claim is not presently adequately defined. And its >>> definition will of necessity be specific to the introspection >>> application. Therefore, it should not be registered as a general JWT >>> claim name. A name I would be comfortable with for this concept would >>> be urn:ietf:params:oauth:introspection:active, since it makes it clear >>> what application the name is used with. >>> >>> >>> >>> “user_id” – The concept you’re describing is almost universally called >>> “username”. User ID is typically the numeric account identifier >>> (carried in the “sub” claim in a JWT), and so is not the right name >>> for this. Compare it to the preferred_username claim in OpenID >>> Connect. Please change this either to “username” or >>> urn:ietf:params:oauth:introspection:username. >>> >>> >>> >>> “token_type” – While this is well-defined, the usage is fairly >>> specific to this application. Again, adding the >>> urn:ietf:params:oauth:introspection: name prefix would address this issue. >>> >>> >>> >>> If you give up registering these names in the JWT Claims registry, I’m >>> OK with you using short names. But if you want them to live alongside >>> other JWT claim names, please include the >>> urn:ietf:params:oauth:introspection: in lieu of registration. >>> >>> >>> >>> Thank you, >>> >>> -- Mike >>> >>> >>> >>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer >>> *Sent:* Wednesday, March 04, 2015 1:46 PM >>> *To:* Hannes Tschofenig >>> *Cc:* >>> *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token >>> Introspection "Claims" >>> >>> >>> >>> Hi Hannes, thanks for the feedback. Responses inline. >>> >>> >>> >>> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig >>> > wrote: >>> >>> >>> >>> Hi Justin, Hi all, >>> >>> in OAuth we provide two ways for a resource server to make an >>> authorization decision. >>> >>> 1) The resource server receives a self-contained token that >>> contains all >>> the necessary information to make a local authorization decision. With >>> the JWT we have created such a standardized information and data >>> model. >>> >>> 2) With an access request from a client the resource server asks the >>> authorization server for "help". The authorization server provides >>> information that help make the authorization decision. This is the >>> token >>> introspection approach. >>> >>> I believe the two approaches need to be aligned with regard to the >>> information and the data model. Since both documents already use >>> JSON as >>> a way to encode information (=data model) and almost have an identical >>> information model (the data that is being passed around). >>> >>> What needs to be done? >>> >>> * Use the term 'claims' in both documents. >>> * Use the same registry (i.e., the registry established with the JWT). >>> * Register the newly defined claims from the token introspection >>> document in the claims registry. >>> >>> >>> >>> We’ve already done this in the latest draft. Or at least, that’s the >>> intent of the current text — the registry is referenced and the new >>> claims are registered. Can you specifically point to places where this >>> needs to be improved upon? >>> >>> >>> >>> Then, I have a few comments on the new claims that are proposed: >>> >>> Here is the definition of the 'active' claim: >>> >>> active >>> REQUIRED. Boolean indicator of whether or not the presented token >>> is currently active. The authorization server determines whether >>> and when a given token is in an active state. >>> >>> This claim is not well-defined. You need to explain what "active" means. >>> It could, for example, mean that the token is not yet expired. Then, >>> there is of course the question why you are not returning the 'exp' >>> claim together with the 'nbf' claim. >>> >>> >>> >>> The definition of “active” is really up to the authorization server, >>> and I’ve yet to hear from an actual implementor who’s confused by this >>> definition. When you’re the one issuing the tokens, you know what an >>> “active” token means to you. Still, perhaps we can be even more >>> explicit, such as: >>> >>> >>> >>> >>> >>> active >>> >>> REQUIRED. Boolean indicator of whether or not the presented >>> token is currently active. The specifics of a token’s active state >>> will vary depending on the implementation of the authorization >>> server, but generally this will indicate that a given token has >>> been issued by this authorization server, has not been revoked by >>> the resource owner, and is within its given time window of >>> validity (e.g. not expired). >>> >>> >>> >>> Also, this is one of the places where the overlap between JWT and >>> introspection claims don’t make sense. It doesn’t make any sense for a >>> JWT to carry an “active” claim at all. Why would you have a JWT claim >>> to be anything but active? We should register it with the JWT registry >>> to avoid name collisions, but there’s nothing in the JWT registry that >>> says “don’t use this inside of a JWT”. Do you have any advice on how >>> to address this? >>> >>> >>> >>> >>> client_id: What is the resource server going to do with the client_id? >>> What authorization decision could it make? >>> >>> >>> >>> Whatever it wants to. If an RS can figure out something from the >>> client_id, why not let it? The client_id is a piece of information >>> about the context of the issuance of the token, and a common enough >>> OAuth value for decision making. >>> >>> >>> >>> I have a couple of reactions when I read the 'user_id' claim: >>> - I believe the inclusion of a user id field in the response could >>> lead to further confusion regarding OAuth access token usage for >>> authentication. >>> >>> >>> >>> This isn’t any different from having a userinfo-endpoint equivalent >>> (like social graph or twitter API) and it’s got the same trouble. >>> >>> >>> >>> >>> - Since you define it as a human readable identifier I am wondering >>> whether you want to say something about the usage. Here it seems that it >>> might be used for displaying something on a webpage rather than making >>> an authorization decision but I might well be wrong. >>> >>> >>> >>> We added in “user_id” to our implementation due to developer demand — >>> they wanted a username associated with the return value, but to leave >>> the “sub” value the same as that defined by OpenID Connect. Note that >>> this is in an environment where the username is a known quantity, and >>> they’re not trying to do cross-domain authentication. They just want >>> to know whose token this was so they can figure out whose data to >>> return. It’s not used for display, but I tried to make the definition >>> in contrast to the machine-facing “sub” value. >>> >>> >>> >>> >>> - I am missing a discussion about the privacy implications of it. >>> While there is a privacy consideration section I am wondering what >>> controls the release of this sensitive information from the >>> authorization server to the resource server. While in some cases the two >>> parties might belong to the same organization but in other cases that >>> may not necessarily be true. >>> >>> >>> >>> You’re correct, this is currently missing and I’ll add that in. >>> >>> >>> >>> >>> - In terms of the information exchanged about the user I am curious >>> about the usefulness of including other information as well, such as the >>> info that is included in an id token (see >>> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this >>> has nothing to do with the ID token concept and the information carried >>> within it then I would add that remark. >>> >>> >>> >>> >>> >>> You could introspect an ID token if you wanted to, but it’s usually >>> easier to just parse it yourself because it’s self-contained. The ID >>> Token also extends JWT, so there’s nothing stopping you from returning >>> those claims as well. However, note that the audience of the ID token >>> is the OAuth *client* whereas the targeted user of the introspection >>> endpoint is the *protected resource*. The PR isn’t going to see the ID >>> Token most of the time, and the client’s not going to need to (or be >>> able to) introspect its tokens most of the time, so in practice >>> there’s not really any overlap. >>> >>> >>> >>> — Justin >>> >>> >>> >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> From nobody Thu Mar 5 04:25:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1509B1A8783 for ; Thu, 5 Mar 2015 04:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 C_xQhlNaIh28 for ; Thu, 5 Mar 2015 04:25:45 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04091A8729 for ; Thu, 5 Mar 2015 04:25:44 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-15-54f84b47b02d 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 56.4C.08135.74B48F45; Thu, 5 Mar 2015 07:25:43 -0500 (EST) 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 t25CPgcq004369; Thu, 5 Mar 2015 07:25:42 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t25CPeTS023023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 07:25:41 -0500 Message-ID: <54F84B3D.1090401@mit.edu> Date: Thu, 05 Mar 2015 07:25:33 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mike Jones , Hannes Tschofenig References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------080708090902070806090102" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixCmqrevu/SPEYPl7UYulO++xWuyd9onF 4uTbV2wOzB6LN+1n81iy5CeTR+uOv+wBzFFcNimpOZllqUX6dglcGXeu/2YquLSDqeLm9/fs DYz7LjB2MXJySAiYSCz7c5IJwhaTuHBvPVsXIxeHkMBiJonVRzvZIZwNjBKb/98GqxISuMUk sXWrGIjNK6Amsf3FHXYQm0VAVeLzsY0sIDYbkD19TQtYvahAlETPn242iHpBiZMzn4DViAik SFxoXgRWwyygLtH7eyUriC0sECCxYttJVojFs5gk5h/8DVbEKZAosXPpMjaIhjCJZQ1z2Scw CsxCMncWktQsRg4g21Zi+mFpiLC8RPPW2cwQtq7E3q7LLMjiCxjZVjHKpuRW6eYmZuYUpybr Ficn5uWlFuka6eVmluilppRuYgRHgiTvDsZ3B5UOMQpwMCrx8H7Y/D1EiDWxrLgy9xCjJAeT kihvsPGPECG+pPyUyozE4oz4otKc1OJDjBIczEoivPlaQDnelMTKqtSifJiUNAeLkjjvph98 IUIC6YklqdmpqQWpRTBZGQ4OJQlefi+gRsGi1PTUirTMnBKENBMHJ8hwHqDhyiA1vMUFibnF mekQ+VOMilLivB88gRICIImM0jy4XliiesUoDvSKMO8fkCoeYJKD634FNJgJaLCWGNjgkkSE lFQDY0TZxCZjAV+5E03mc43/Xmtf33PvQcuhqsBPYh5vwwVim4Ncmtwl3a00BS3sDlkXXd6w QyVN6b6pQs7yGu9d09IWdVQcMdPsviBR5XogSTWbrb+tyWT7wtVNTHe4hORX7HHTFzRoD7X/ m241t/7ffVPdp4EKv/ZPEl/YrpSmKbolNuQY/wslluKMREMt5qLiRAAIUgSeLwMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:25:50 -0000 This is a multi-part message in MIME format. --------------080708090902070806090102 Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry? -- Justin On 3/5/2015 2:36 AM, Mike Jones wrote: > It sounds to me like you're making a good argument for this spec to > have its own registry. Registries are easy to establish and use. > ------------------------------------------------------------------------ > From: Justin Richer > Sent: ý3/ý4/ý2015 6:43 PM > To: Mike Jones ; Hannes Tschofenig > > Cc: > Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token > Introspection "Claims" > > I'm actually fine with keeping the introspection-specific elements out > of the registry (see my note on "active" and how it doesn't fit in JWT > below), but I do not want to give up the short names. The short names > are already in production, especially "active", which is well > understood and used in practice today, and has been for years[1]. > Changing this would fundamentally break all existing implementations > for no good reason. I'm slightly more OK with changing "user_id" to > "username", since that's not as widely deployed to my knowledge (other > implementers, please pipe up if I'm mistaken), and I'm well familiar > with "preffered_username" in OIDC because I'm the one that put it in > there [2]. :) While I prefer to leave it be at this stage, I think > this is a less destructive change than "active", "scope", or > "client_id" would be. > > For background to my stance regarding the registry: several revisions > (and years) ago, the introspection draft re-defined several fields > that overlapped with JWT and we were asked to correlate the two. > Originally, we simply had a pointer to re-use the JWT claims as > defined, and stacked our own claims on top. Later, we were asked to > outright merge them, which is what we have right now. If the WG wants > to back off that last change to the middle state -- where we re-use > the JWT registry but don't write to it -- I'm very happy with that > result and can work that (back) into the next draft. > > Though it does point out something strange about the standards process > that we're running into here: JWT needed a place to register bits of > metadata about a token, so it created one. This became the "JWT > registry", and now it's got hangings of being "JWT-specific". When > introspection came along with a need to talk about much the same kind > of information, it makes sense to re-use the existing items but also > that there would be things that are introspection-specific. > > -- Justin > > [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 > [2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim > > On 3/4/2015 6:28 PM, Mike Jones wrote: >> >> I have severe concerns with this approach. It’s not appropriate to >> register arbitrary JSON object member names as JWT claim names – >> especially when the JSON object member names are not even being used >> as JWT claim names. *Please do not do this*, as it would needlessly >> pollute the JWT claim name namespace with registered names that are >> application specific. >> >> Secondarily, I have concerns about these names and suggestions for >> how to address them. >> >> “active” – This claim is not presently adequately defined. And its >> definition will of necessity be specific to the introspection >> application. Therefore, it should not be registered as a general JWT >> claim name. A name I would be comfortable with for this concept >> would be urn:ietf:params:oauth:introspection:active, since it makes >> it clear what application the name is used with. >> >> “user_id” – The concept you’re describing is almost universally >> called “username”. User ID is typically the numeric account >> identifier (carried in the “sub” claim in a JWT), and so is not the >> right name for this. Compare it to the preferred_username claim in >> OpenID Connect. Please change this either to “username” or >> urn:ietf:params:oauth:introspection:username. >> >> “token_type” – While this is well-defined, the usage is fairly >> specific to this application. Again, adding the >> urn:ietf:params:oauth:introspection: name prefix would address this >> issue. >> >> If you give up registering these names in the JWT Claims registry, >> I’m OK with you using short names. But if you want them to live >> alongside other JWT claim names, please include the >> urn:ietf:params:oauth:introspection: in lieu of registration. >> >> Thank you, >> >> -- Mike >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer >> *Sent:* Wednesday, March 04, 2015 1:46 PM >> *To:* Hannes Tschofenig >> *Cc:* >> *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token >> Introspection "Claims" >> >> Hi Hannes, thanks for the feedback. Responses inline. >> >> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig >> > wrote: >> >> Hi Justin, Hi all, >> >> in OAuth we provide two ways for a resource server to make an >> authorization decision. >> >> 1) The resource server receives a self-contained token that >> contains all >> the necessary information to make a local authorization decision. >> With >> the JWT we have created such a standardized information and data >> model. >> >> 2) With an access request from a client the resource server asks the >> authorization server for "help". The authorization server provides >> information that help make the authorization decision. This is >> the token >> introspection approach. >> >> I believe the two approaches need to be aligned with regard to the >> information and the data model. Since both documents already use >> JSON as >> a way to encode information (=data model) and almost have an >> identical >> information model (the data that is being passed around). >> >> What needs to be done? >> >> * Use the term 'claims' in both documents. >> * Use the same registry (i.e., the registry established with the >> JWT). >> * Register the newly defined claims from the token introspection >> document in the claims registry. >> >> We’ve already done this in the latest draft. Or at least, that’s the >> intent of the current text — the registry is referenced and the new >> claims are registered. Can you specifically point to places where >> this needs to be improved upon? >> >> >> >> Then, I have a few comments on the new claims that are proposed: >> >> Here is the definition of the 'active' claim: >> >> active >> REQUIRED. Boolean indicator of whether or not the presented token >> is currently active. The authorization server determines whether >> and when a given token is in an active state. >> >> This claim is not well-defined. You need to explain what "active" means. >> It could, for example, mean that the token is not yet expired. Then, >> there is of course the question why you are not returning the 'exp' >> claim together with the 'nbf' claim. >> >> The definition of “active” is really up to the authorization server, >> and I’ve yet to hear from an actual implementor who’s confused by >> this definition. When you’re the one issuing the tokens, you know >> what an “active” token means to you. Still, perhaps we can be even >> more explicit, such as: >> >> active >> >> REQUIRED. Boolean indicator of whether or not the presented >> token is currently active. The specifics of a token’s active >> state will vary depending on the implementation of the >> authorization server, but generally this will indicate that a >> given token has been issued by this authorization server, has not >> been revoked by the resource owner, and is within its given time >> window of validity (e.g. not expired). >> >> Also, this is one of the places where the overlap between JWT and >> introspection claims don’t make sense. It doesn’t make any sense for >> a JWT to carry an “active” claim at all. Why would you have a JWT >> claim to be anything but active? We should register it with the JWT >> registry to avoid name collisions, but there’s nothing in the JWT >> registry that says “don’t use this inside of a JWT”. Do you have any >> advice on how to address this? >> >> >> >> >> client_id: What is the resource server going to do with the client_id? >> What authorization decision could it make? >> >> Whatever it wants to. If an RS can figure out something from the >> client_id, why not let it? The client_id is a piece of information >> about the context of the issuance of the token, and a common enough >> OAuth value for decision making. >> >> >> >> I have a couple of reactions when I read the 'user_id' claim: >> - I believe the inclusion of a user id field in the response could >> lead to further confusion regarding OAuth access token usage for >> authentication. >> >> This isn’t any different from having a userinfo-endpoint equivalent >> (like social graph or twitter API) and it’s got the same trouble. >> >> >> >> >> - Since you define it as a human readable identifier I am wondering >> whether you want to say something about the usage. Here it seems that it >> might be used for displaying something on a webpage rather than making >> an authorization decision but I might well be wrong. >> >> We added in “user_id” to our implementation due to developer demand — >> they wanted a username associated with the return value, but to leave >> the “sub” value the same as that defined by OpenID Connect. Note that >> this is in an environment where the username is a known quantity, and >> they’re not trying to do cross-domain authentication. They just want >> to know whose token this was so they can figure out whose data to >> return. It’s not used for display, but I tried to make the definition >> in contrast to the machine-facing “sub” value. >> >> >> >> >> - I am missing a discussion about the privacy implications of it. >> While there is a privacy consideration section I am wondering what >> controls the release of this sensitive information from the >> authorization server to the resource server. While in some cases the two >> parties might belong to the same organization but in other cases that >> may not necessarily be true. >> >> You’re correct, this is currently missing and I’ll add that in. >> >> >> >> >> - In terms of the information exchanged about the user I am curious >> about the usefulness of including other information as well, such as the >> info that is included in an id token (see >> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this >> has nothing to do with the ID token concept and the information carried >> within it then I would add that remark. >> >> You could introspect an ID token if you wanted to, but it’s usually >> easier to just parse it yourself because it’s self-contained. The ID >> Token also extends JWT, so there’s nothing stopping you from >> returning those claims as well. However, note that the audience of >> the ID token is the OAuth *client* whereas the targeted user of the >> introspection endpoint is the *protected resource*. The PR isn’t >> going to see the ID Token most of the time, and the client’s not >> going to need to (or be able to) introspect its tokens most of the >> time, so in practice there’s not really any overlap. >> >> — Justin >> >> >> >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --------------080708090902070806090102 Content-Type: text/html; charset=windows-1256 Content-Transfer-Encoding: 8bit I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry?

 -- Justin

On 3/5/2015 2:36 AM, Mike Jones wrote:
It sounds to me like you're making a good argument for this spec to have its own registry.  Registries are easy to establish and use.
From: Justin Richer
Sent: ý3/ý4/ý2015 6:43 PM
To: Mike Jones; Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on "active" and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially "active", which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing "user_id" to "username", since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with "preffered_username" in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than "active", "scope", or "client_id" would be.

For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft.

Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the "JWT registry", and now it's got hangings of being "JWT-specific". When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific.

 -- Justin

[1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03
[2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim

On 3/4/2015 6:28 PM, Mike Jones wrote:

I have severe concerns with this approach.  It’s not appropriate to register arbitrary JSON object member names as JWT claim names – especially when the JSON object member names are not even being used as JWT claim names.  Please do not do this, as it would needlessly pollute the JWT claim name namespace with registered names that are application specific.

 

Secondarily, I have concerns about these names and suggestions for how to address them.

 

“active” – This claim is not presently adequately defined.  And its definition will of necessity be specific to the introspection application.  Therefore, it should not be registered as a general JWT claim name.  A name I would be comfortable with for this concept would be urn:ietf:params:oauth:introspection:active, since it makes it clear what application the name is used with.

 

“user_id” – The concept you’re describing is almost universally called “username”.  User ID is typically the numeric account identifier (carried in the “sub” claim in a JWT), and so is not the right name for this.  Compare it to the preferred_username claim in OpenID Connect.  Please change this either to “username” or urn:ietf:params:oauth:introspection:username.

 

“token_type” – While this is well-defined, the usage is fairly specific to this application.  Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue.

 

If you give up registering these names in the JWT Claims registry, I’m OK with you using short names.  But if you want them to live alongside other JWT claim names, please include the urn:ietf:params:oauth:introspection: in lieu of registration.

 

                                                            Thank you,

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, March 04, 2015 1:46 PM
To: Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

 

Hi Hannes, thanks for the feedback. Responses inline.

 

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

 

Hi Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=data model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

* Use the term 'claims' in both documents.
* Use the same registry (i.e., the registry established with the JWT).
* Register the newly defined claims from the token introspection
document in the claims registry.

 

We’ve already done this in the latest draft. Or at least, that’s the intent of the current text — the registry is referenced and the new claims are registered. Can you specifically point to places where this needs to be improved upon?



Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

  active
     REQUIRED.  Boolean indicator of whether or not the presented token
     is currently active.  The authorization server determines whether
     and when a given token is in an active state.

This claim is not well-defined. You need to explain what "active" means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

 

The definition of “active” is really up to the authorization server, and I’ve yet to hear from an actual implementor who’s confused by this definition. When you’re the one issuing the tokens, you know what an “active” token means to you. Still, perhaps we can be even more explicit, such as:

 

 

active

  REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token’s active state will vary depending on the implementation of the authorization server, but generally this will indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g. not expired). 

 

Also, this is one of the places where the overlap between JWT and introspection claims don’t make sense. It doesn’t make any sense for a JWT to carry an “active” claim at all. Why would you have a JWT claim to be anything but active? We should register it with the JWT registry to avoid name collisions, but there’s nothing in the JWT registry that says “don’t use this inside of a JWT”. Do you have any advice on how to address this?




client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

 

Whatever it wants to. If an RS can figure out something from the client_id, why not let it? The client_id is a piece of information about the context of the issuance of the token, and a common enough OAuth value for decision making. 



I have a couple of reactions when I read the 'user_id' claim:
 - I believe the inclusion of a user id field in the response could
lead to further confusion regarding OAuth access token usage for
authentication.

 

This isn’t any different from having a userinfo-endpoint equivalent (like social graph or twitter API) and it’s got the same trouble. 




 - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

 

We added in “user_id” to our implementation due to developer demand — they wanted a username associated with the return value, but to leave the “sub” value the same as that defined by OpenID Connect. Note that this is in an environment where the username is a known quantity, and they’re not trying to do cross-domain authentication. They just want to know whose token this was so they can figure out whose data to return. It’s not used for display, but I tried to make the definition in contrast to the machine-facing “sub” value.




 - I am missing a discussion about the privacy implications of it.
While there is a privacy consideration section I am wondering what
controls the release of this sensitive information from the
authorization server to the resource server. While in some cases the two
parties might belong to the same organization but in other cases that
may not necessarily be true.

 

You’re correct, this is currently missing and I’ll add that in.




 - In terms of the information exchanged about the user I am curious
about the usefulness of including other information as well, such as the
info that is included in an id token (see
http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this
has nothing to do with the ID token concept and the information carried
within it then I would add that remark.

 

 

You could introspect an ID token if you wanted to, but it’s usually easier to just parse it yourself because it’s self-contained. The ID Token also extends JWT, so there’s nothing stopping you from returning those claims as well. However, note that the audience of the ID token is the OAuth *client* whereas the targeted user of the introspection endpoint is the *protected resource*. The PR isn’t going to see the ID Token most of the time, and the client’s not going to need to (or be able to) introspect its tokens most of the time, so in practice there’s not really any overlap.

 

 — Justin




Ciao
Hannes

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

 



--------------080708090902070806090102-- From nobody Thu Mar 5 04:43:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209DD1A871A for ; Thu, 5 Mar 2015 04:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_RP_RNBL=1.31, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ftyeapOUUU9O for ; Thu, 5 Mar 2015 04:43:30 -0800 (PST) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.42]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDE61A0204 for ; Thu, 5 Mar 2015 04:43:29 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LeNGL-1XgSFU3gXl-00q8ii; Thu, 05 Mar 2015 13:43:26 +0100 Message-ID: <54F84F69.2090408@gmx.net> Date: Thu, 05 Mar 2015 13:43:21 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Bradley References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5fhOHcRrwnBmIOvEljOs7Gm5U8e8F3kvO" X-Provags-ID: V03:K0:85I5OcbEPtBQ2jimNytFKYKIe5Uh+vcqnYRgReFs4tEXlOF2PGG hXKCRNmPbsuaTn6fX2sxwLuG2NWkApP44/RyH1eT35DQN/lzdPydu0NhaXyn959vQ9S0+q/ ONo1vrFt/YfVjQgOEIQihH4CW4znatE2SP5uFy14fFMHy6bkfmCrFwvCmkySPHNu0P5qN8q KHbEJvzPiaRBuUEtYfCNg== X-UI-Out-Filterresults: junk:10; Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:43:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5fhOHcRrwnBmIOvEljOs7Gm5U8e8F3kvO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi John, that's a good idea. However, the dynamic client registration should state that the "kid" parameter is used and must be included in the JWK (since the kid is an optional parameter). The key name is then the 'kid' plus the client id since the value of the kid is not unique by itself. Ciao Hannes On 03/05/2015 12:54 PM, John Bradley wrote: > For signing authentication requests you include the keyid in the JWT, a= nd the AS looks in the JWKS to find the correct key if there is more than= one. >=20 > I don't think that is a problem >=20 > What we probably need to do is pass a keyid in the request if there is = more than one signing key registered for the client. >=20 > John B. --5fhOHcRrwnBmIOvEljOs7Gm5U8e8F3kvO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+E9qAAoJEGhJURNOOiAtzjoH/RFJH3cBFLJpL+1tUtFwLdfr iRPO5QkB8yh9xwZnNlvXTvG7mWqVb+v0Fmf6HdUita0oSiOc9sXrLLWqckC/BP/5 5xbudBNkjcfwpLnUtdID4fMl7CePv6s/oKYuaK9zwyTedTEfOUpn2oM5acs6TZQ3 NsFF1kj9SPfqd2DHNcwCT+vtCrHW/xcadiPGaP2DJ8yHKRUeUy7Gmo5O/3SxCvBi oVg7ElCvxd0ekNj7+xtXquITmTx460YPsh+5anj8STHQYOZ5MHSF8DaQfAt5YnU/ xcqSslMI5TwIINgGBzo86EHk4w3xJSTIATUf2x9H0CnTKun99SgXAH61gYuekRc= =sB08 -----END PGP SIGNATURE----- --5fhOHcRrwnBmIOvEljOs7Gm5U8e8F3kvO-- From nobody Thu Mar 5 04:53:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7833D1A871A for ; Thu, 5 Mar 2015 04:53:20 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2v_gN81AAymV for ; Thu, 5 Mar 2015 04:53:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCAD1A1A67 for ; Thu, 5 Mar 2015 04:53:16 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LpObx-1XrP6D1zVd-00fAYe; Thu, 05 Mar 2015 13:53:13 +0100 Message-ID: <54F851B6.9040302@gmx.net> Date: Thu, 05 Mar 2015 13:53:10 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Justin Richer , Mike Jones References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F8164E.6040201@gmx.net> <54F84AC8.50109@mit.edu> In-Reply-To: <54F84AC8.50109@mit.edu> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5E2tQ3JbDuSEHiR2vlSD6QhJHftr5oQA4" X-Provags-ID: V03:K0:t5Fj73ll1EszCxNjCr5mYreB4jK6Yz9lNRMMmbMGUY+fsDAZ9Hs lIjRAJI3QOPA1o0tr9NuJa5saeXwnxR4vFEGh77/HCPUgIYTv4M1n7qgXs5Y/EjHmQL6h70 rJRjw+33SgNp3SHUmR/elFka6vnJuHxKa92QcAOgOOxLfLC49Mt7G8etBaViPJkW7scmeyG QcP9D91Kh8HBpsCJeDU2w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:53:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5E2tQ3JbDuSEHiR2vlSD6QhJHftr5oQA4 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: quoted-printable Hi Justin, in a security specification we should be able to say exactly what the semantic of a certain attribute is. What I expect happening today is that many organizations provide both resource server and authorization server and agree in an out-of-band fashion what the meaning of that value is. This is why we don't hear back from implementers at this point in time. This is, however, not the purpose of standardization. We want to develop a spec that allows two different vendors to plug their stuff together and it works without having to agree (out of band) what the semantic if the different fields is. We have already seen in OAuth that vague text does not increase security.= If the purpose of the active claim is only to say that the AS did some checks without further indicating what it actually did then we could as well use the fact that there has been a response to the request (rather than an error message) as well. That seems to be roughly the level of semantic we are at with this at the moment. I hope you understand that I have to push back on these hand-wavy ideas since otherwise we need profiles in other organizations that explain what the IETF OAuth documents really mean. Ciao Hannes On 03/05/2015 01:23 PM, Justin Richer wrote: > The "active" claim boils down to the AS saying "Do I think this token i= s > any good or not?" and it's really up to the AS how it determines that. > Our own implementation does a data store lookup on the token value. If > it finds the token, then the token is active. If the token had been > revoked, or expired, then it wouldn't have come out of the data store i= n > the first place, and it's not active. I've seen others do the same thin= g. >=20 > Other stateless implementations are going to probably parse the token > itself and do things like check claims and signatures to see if the > token's any good. Or they might decrypt the token at the AS (assuming i= n > this example that it was encrypted using the AS's key) and dig inside > the protected structure that's not available to the RS. Once it's insid= e > that structure the AS can figure out if the token's active or not, and > tell the RS. >=20 > Or there might be a combination of the two where the AS parses the toke= n > and checks its signature and then uses some key field in the token to > look up more information in a data store. If all that checks out then > the token is active, probably. >=20 > And the AS might want to do other checks, like see if this particular R= S > is even allowed to ask about this particular token. >=20 > It is not, however, just a sanity check across other claims already > embedded in the token -- you could very easily use an unstructured > token. In fact, that's the world that this was first deployed in back > 4-5 years ago. >=20 > The important thing is that as far as the RS is concerned, the AS did > *some* check on the token and came back with a thumbs up / thumbs down > response. The thumbs up response can contain other information as well,= > such as scopes and client IDs and whatnot, which can help the RS make > its authorization decision. But at its core, the "active" claim > fundamentally says "is this token any good at all, according to the AS > that I asked?" and the RS can make its primary authorization decision > based on that. If the RS has made the decision to outsource the token > validity check to the AS, then the RS either understands or doesn't car= e > what checks the AS makes in its decision regardless of implementation o= r > vendor. Either way, it will abide by them since that's the whole point > of outsourcing that decision. >=20 >=20 > And I think you're too quick to dismiss the lack of confusion on the > part of developers, considering that they are in fact the target > audience of specifications like this. If we're not writing these > documents for developers, who are we writing them for? >=20 > -- Justin >=20 > On 3/5/2015 3:39 AM, Hannes Tschofenig wrote: >> Hi Mike, Hi Justin, >> >> I guess you agree with me that fundamentally the JWT and the token >> introspection solve the same problem, namely to provide the >> authorization server with information that it can use to make an >> authorization decision. The difference is only in the way how the >> message flows. >> >> Now, to the argument that developers have not yet complained about the= >> underspecified claims/attributes is not particularly good. We tend to >> hear about complains years later when things go wrong and then we cann= ot >> change them anymore. >> >> Tell me for the active claim what type of checks the authorization >> server is supposed to do. >> >> If the authorization server and the resource server are provided by >> different parties then it is important to be clear about what checks >> each of the two parties are supposed to be doing. If the active claim >> aims to outsource the authorization decision from the resource server = to >> the authorization server then that's a completely different story than= >> just doing some basic sanity check on some of the JWT claims. >> >> Ciao >> Hannes >> >> >> On 03/05/2015 08:36 AM, Mike Jones wrote: >>> It sounds to me like you're making a good argument for this spec to h= ave >>> its own registry. Registries are easy to establish and use. >>> ---------------------------------------------------------------------= --- >>> From: Justin Richer >>> Sent: =FD3/=FD4/=FD2015 6:43 PM >>> To: Mike Jones ; Hannes Tschofeni= g >>> >>> Cc: >>> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspecti= on >>> "Claims" >>> >>> I'm actually fine with keeping the introspection-specific elements ou= t >>> of the registry (see my note on "active" and how it doesn't fit in JW= T >>> below), but I do not want to give up the short names. The short names= >>> are already in production, especially "active", which is well underst= ood >>> and used in practice today, and has been for years[1]. Changing this >>> would fundamentally break all existing implementations for no good >>> reason. I'm slightly more OK with changing "user_id" to "username", >>> since that's not as widely deployed to my knowledge (other implemente= rs, >>> please pipe up if I'm mistaken), and I'm well familiar with >>> "preffered_username" in OIDC because I'm the one that put it in there= >>> [2]. :) While I prefer to leave it be at this stage, I think this is = a >>> less destructive change than "active", "scope", or "client_id" would = be. >>> >>> For background to my stance regarding the registry: several revisions= >>> (and years) ago, the introspection draft re-defined several fields th= at >>> overlapped with JWT and we were asked to correlate the two. Originall= y, >>> we simply had a pointer to re-use the JWT claims as defined, and stac= ked >>> our own claims on top. Later, we were asked to outright merge them, >>> which is what we have right now. If the WG wants to back off that las= t >>> change to the middle state -- where we re-use the JWT registry but do= n't >>> write to it -- I'm very happy with that result and can work that (bac= k) >>> into the next draft. >>> >>> Though it does point out something strange about the standards proces= s >>> that we're running into here: JWT needed a place to register bits of >>> metadata about a token, so it created one. This became the "JWT >>> registry", and now it's got hangings of being "JWT-specific". When >>> introspection came along with a need to talk about much the same kind= of >>> information, it makes sense to re-use the existing items but also tha= t >>> there would be things that are introspection-specific. >>> >>> -- Justin >>> >>> [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 >>> [2] >>> https://bitbucket.org/openid/connect/issue/584/messages-username-clai= m >>> >>> On 3/4/2015 6:28 PM, Mike Jones wrote: >>>> I have severe concerns with this approach. It=92s not appropriate t= o >>>> register arbitrary JSON object member names as JWT claim names =96 >>>> especially when the JSON object member names are not even being used= >>>> as JWT claim names. *Please do not do this*, as it would needlessly= >>>> pollute the JWT claim name namespace with registered names that are >>>> application specific. >>>> >>>> =20 >>>> Secondarily, I have concerns about these names and suggestions for h= ow >>>> to address them. >>>> >>>> =20 >>>> =93active=94 =96 This claim is not presently adequately defined. An= d its >>>> definition will of necessity be specific to the introspection >>>> application. Therefore, it should not be registered as a general JW= T >>>> claim name. A name I would be comfortable with for this concept wou= ld >>>> be urn:ietf:params:oauth:introspection:active, since it makes it cle= ar >>>> what application the name is used with. >>>> >>>> =20 >>>> =93user_id=94 =96 The concept you=92re describing is almost universa= lly called >>>> =93username=94. User ID is typically the numeric account identifier= >>>> (carried in the =93sub=94 claim in a JWT), and so is not the right n= ame >>>> for this. Compare it to the preferred_username claim in OpenID >>>> Connect. Please change this either to =93username=94 or >>>> urn:ietf:params:oauth:introspection:username. >>>> >>>> =20 >>>> =93token_type=94 =96 While this is well-defined, the usage is fairly= >>>> specific to this application. Again, adding the >>>> urn:ietf:params:oauth:introspection: name prefix would address this >>>> issue. >>>> >>>> =20 >>>> If you give up registering these names in the JWT Claims registry, I= =92m >>>> OK with you using short names. But if you want them to live alongsi= de >>>> other JWT claim names, please include the >>>> urn:ietf:params:oauth:introspection: in lieu of registration. >>>> >>>> =20 >>>> Thank y= ou, >>>> >>>> -- Mike= >>>> >>>> =20 >>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin >>>> Richer >>>> *Sent:* Wednesday, March 04, 2015 1:46 PM >>>> *To:* Hannes Tschofenig >>>> *Cc:* >>>> *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token >>>> Introspection "Claims" >>>> >>>> =20 >>>> Hi Hannes, thanks for the feedback. Responses inline. >>>> >>>> =20 >>>> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig >>>> > >>>> wrote: >>>> >>>> =20 >>>> Hi Justin, Hi all, >>>> >>>> in OAuth we provide two ways for a resource server to make an >>>> authorization decision. >>>> >>>> 1) The resource server receives a self-contained token that >>>> contains all >>>> the necessary information to make a local authorization >>>> decision. With >>>> the JWT we have created such a standardized information and dat= a >>>> model. >>>> >>>> 2) With an access request from a client the resource server >>>> asks the >>>> authorization server for "help". The authorization server provi= des >>>> information that help make the authorization decision. This is = the >>>> token >>>> introspection approach. >>>> >>>> I believe the two approaches need to be aligned with regard to = the >>>> information and the data model. Since both documents already us= e >>>> JSON as >>>> a way to encode information (=3Ddata model) and almost have an >>>> identical >>>> information model (the data that is being passed around). >>>> >>>> What needs to be done? >>>> >>>> * Use the term 'claims' in both documents. >>>> * Use the same registry (i.e., the registry established with >>>> the JWT). >>>> * Register the newly defined claims from the token introspectio= n >>>> document in the claims registry. >>>> >>>> =20 >>>> We=92ve already done this in the latest draft. Or at least, that=92s= the >>>> intent of the current text =97 the registry is referenced and the ne= w >>>> claims are registered. Can you specifically point to places where th= is >>>> needs to be improved upon? >>>> >>>> >>>> >>>> Then, I have a few comments on the new claims that are proposed: >>>> >>>> Here is the definition of the 'active' claim: >>>> >>>> active >>>> REQUIRED. Boolean indicator of whether or not the presented >>>> token >>>> is currently active. The authorization server determines whet= her >>>> and when a given token is in an active state. >>>> >>>> This claim is not well-defined. You need to explain what "active" >>>> means. >>>> It could, for example, mean that the token is not yet expired. Then,= >>>> there is of course the question why you are not returning the 'exp' >>>> claim together with the 'nbf' claim. >>>> >>>> =20 >>>> The definition of =93active=94 is really up to the authorization ser= ver, >>>> and I=92ve yet to hear from an actual implementor who=92s confused b= y this >>>> definition. When you=92re the one issuing the tokens, you know what = an >>>> =93active=94 token means to you. Still, perhaps we can be even more >>>> explicit, such as: >>>> >>>> =20 >>>> =20 >>>> active >>>> >>>> REQUIRED. Boolean indicator of whether or not the presented >>>> token is currently active. The specifics of a token=92s active = state >>>> will vary depending on the implementation of the authorization >>>> server, but generally this will indicate that a given token has= >>>> been issued by this authorization server, has not been revoked = by >>>> the resource owner, and is within its given time window of >>>> validity (e.g. not expired). >>>> >>>> =20 >>>> Also, this is one of the places where the overlap between JWT and >>>> introspection claims don=92t make sense. It doesn=92t make any sense= for a >>>> JWT to carry an =93active=94 claim at all. Why would you have a JWT = claim >>>> to be anything but active? We should register it with the JWT regist= ry >>>> to avoid name collisions, but there=92s nothing in the JWT registry = that >>>> says =93don=92t use this inside of a JWT=94. Do you have any advice = on how >>>> to address this? >>>> >>>> >>>> >>>> >>>> client_id: What is the resource server going to do with the client_i= d? >>>> What authorization decision could it make? >>>> >>>> =20 >>>> Whatever it wants to. If an RS can figure out something from the >>>> client_id, why not let it? The client_id is a piece of information >>>> about the context of the issuance of the token, and a common enough >>>> OAuth value for decision making. >>>> >>>> >>>> >>>> I have a couple of reactions when I read the 'user_id' claim: >>>> - I believe the inclusion of a user id field in the response could= >>>> lead to further confusion regarding OAuth access token usage for >>>> authentication. >>>> >>>> =20 >>>> This isn=92t any different from having a userinfo-endpoint equivalen= t >>>> (like social graph or twitter API) and it=92s got the same trouble. >>>> >>>> >>>> >>>> >>>> - Since you define it as a human readable identifier I am wonderin= g >>>> whether you want to say something about the usage. Here it seems >>>> that it >>>> might be used for displaying something on a webpage rather than maki= ng >>>> an authorization decision but I might well be wrong. >>>> >>>> =20 >>>> We added in =93user_id=94 to our implementation due to developer dem= and =97 >>>> they wanted a username associated with the return value, but to leav= e >>>> the =93sub=94 value the same as that defined by OpenID Connect. Note= that >>>> this is in an environment where the username is a known quantity, an= d >>>> they=92re not trying to do cross-domain authentication. They just wa= nt >>>> to know whose token this was so they can figure out whose data to >>>> return. It=92s not used for display, but I tried to make the definit= ion >>>> in contrast to the machine-facing =93sub=94 value. >>>> >>>> >>>> >>>> >>>> - I am missing a discussion about the privacy implications of it. >>>> While there is a privacy consideration section I am wondering what >>>> controls the release of this sensitive information from the >>>> authorization server to the resource server. While in some cases the= >>>> two >>>> parties might belong to the same organization but in other cases tha= t >>>> may not necessarily be true. >>>> >>>> =20 >>>> You=92re correct, this is currently missing and I=92ll add that in. >>>> >>>> >>>> >>>> >>>> - In terms of the information exchanged about the user I am curiou= s >>>> about the usefulness of including other information as well, such as= >>>> the >>>> info that is included in an id token (see >>>> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If th= is >>>> has nothing to do with the ID token concept and the information carr= ied >>>> within it then I would add that remark. >>>> >>>> =20 >>>> =20 >>>> You could introspect an ID token if you wanted to, but it=92s usuall= y >>>> easier to just parse it yourself because it=92s self-contained. The = ID >>>> Token also extends JWT, so there=92s nothing stopping you from retur= ning >>>> those claims as well. However, note that the audience of the ID toke= n >>>> is the OAuth *client* whereas the targeted user of the introspection= >>>> endpoint is the *protected resource*. The PR isn=92t going to see th= e ID >>>> Token most of the time, and the client=92s not going to need to (or = be >>>> able to) introspect its tokens most of the time, so in practice >>>> there=92s not really any overlap. >>>> >>>> =20 >>>> =97 Justin >>>> >>>> >>>> >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> =20 >=20 --5E2tQ3JbDuSEHiR2vlSD6QhJHftr5oQA4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+FG2AAoJEGhJURNOOiAt5U0H/1lXfWc7dUtTOr5HGh57DKHC 2nmjbysbXJAHI8UtIRLdJJ7KE0kPYUucg+k6PJP+xJPaLNLWee7qWue+1NeaEqjK lgaS5HBKSFI5cjahkelElwCuWG7WBCGu8Er8kCqy7wMNNqpOCTVrQTvyPrUy1K9R aM8jCG9MbH1NPaxl5cYLOgRr96K3YnMUuoB5YrDkOaM810v1ZVla6SF2np8vlxxa 7/b8+So591OhRDkA6K6dIgb8Do7h4eUDuWdk8WJHfbBdSjWk11pjiSow/tx1/Lis DGMk4/tbhDR1fsPl5Hk+9pq8+XvYcUtQJ1rXkikdwfiftPks+wjJEXnfybNQl0w= =v646 -----END PGP SIGNATURE----- --5E2tQ3JbDuSEHiR2vlSD6QhJHftr5oQA4-- From nobody Thu Mar 5 04:58:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6D51A0318 for ; Thu, 5 Mar 2015 04:58:30 -0800 (PST) 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 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 XjKMYFEYQkjN for ; Thu, 5 Mar 2015 04:58:29 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (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 49CED1A01A9 for ; Thu, 5 Mar 2015 04:58:29 -0800 (PST) Received: by wevk48 with SMTP id k48so6155305wev.5 for ; Thu, 05 Mar 2015 04:58:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=UBCoMA4NEc13aMzK+QU1EHVG5js1ivzVJZdmvy4x0a4=; b=J9RZD105CRCpG+dqN9Mw+WcExOvshbeyeyFVBoocWiTKufQVvqmB/6tc9U77rKbP/V 2jthnLHVZbnm3LG8Ra4DnKAhYUvz6YjadgxwdxKvaYh3FcBS4B35TCF2iQvQTpsVtt7x ECdYBB/F502+DUocdRtJaxiTm7vRgxivGTdnARCi1/Dn2aRzd5Jy7H4qgqjXdJzHmA3B IGdEIVyyuYZj6vnWAvzxUQEpaGWf+ce8Mw836ptBg4pKN300g+IGcd85JLF+iroZHvSg +S4N8DHwXdAUXTupmSSscItDCsMhLvTxDhYEU7+81aB3FrN4BvJpwONn8eCyBigLl0+E 7HaQ== X-Gm-Message-State: ALoCoQlUzgEsjWENXklwRCi7Yh1MlHfB9H0HqzuNghLWiuSuN0wUH52+3HuX6+7TAe7PT04xzzpp X-Received: by 10.194.108.9 with SMTP id hg9mr18832772wjb.68.1425560307999; Thu, 05 Mar 2015 04:58:27 -0800 (PST) Received: from [192.168.43.33] ([95.131.169.235]) by mx.google.com with ESMTPSA id bf8sm8778090wjb.37.2015.03.05.04.58.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 04:58:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (12B466) In-Reply-To: <54F84F69.2090408@gmx.net> Date: Thu, 5 Mar 2015 13:58:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net> <54F84F69.2090408@gmx.net> To: Hannes Tschofenig Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:58:31 -0000 I am ok with saying that the JWK must have keyed if there is more than one k= ey and it SHOULD if there is only one.=20 Sent from my iPhone > On Mar 5, 2015, at 1:43 PM, Hannes Tschofenig w= rote: >=20 > Hi John, >=20 > that's a good idea. However, the dynamic client registration should > state that the "kid" parameter is used and must be included in the JWK > (since the kid is an optional parameter). >=20 > The key name is then the 'kid' plus the client id since the value of the > kid is not unique by itself. >=20 > Ciao > Hannes >=20 >> On 03/05/2015 12:54 PM, John Bradley wrote: >> For signing authentication requests you include the keyid in the JWT, and= the AS looks in the JWKS to find the correct key if there is more than one.= >>=20 >> I don't think that is a problem >>=20 >> What we probably need to do is pass a keyid in the request if there is mo= re than one signing key registered for the client. >>=20 >> John B. >=20 From nobody Thu Mar 5 04:59:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015261A0318 for ; Thu, 5 Mar 2015 04:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 U1X5eTbaTgI5 for ; Thu, 5 Mar 2015 04:59:38 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73CF1A01A9 for ; Thu, 5 Mar 2015 04:59:38 -0800 (PST) X-AuditID: 1209190f-f79546d000007593-3f-54f8533952e0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 1C.E8.30099.93358F45; Thu, 5 Mar 2015 07:59:37 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t25Cxak9021991; Thu, 5 Mar 2015 07:59:37 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t25CxYIJ030699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 07:59:35 -0500 Message-ID: <54F8532F.7000501@mit.edu> Date: Thu, 05 Mar 2015 07:59:27 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Bradley , Hannes Tschofenig References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net> <54F84F69.2090408@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0bUM/hFisOCyrMXSnfdYLU6+fcVm sfruXzYHZo/Fm/azeSxZ8pPJ4/btjSwBzFFcNimpOZllqUX6dglcGUsu/GQu2M5VMXnpJ+YG xlkcXYycHBICJhLH1k5nhrDFJC7cW8/WxcjFISSwmEli1u47LCAJIYENjBLX1tZAJG4xScw4 cokRJMEroCYx59FqMJtFQFVi874esElsQPb0NS1MILaoQJREz59uNoh6QYmTM5+ADRURiJFY en8GO4jNDFS/fvVFsHphgSCJHZt2skMs+8QoMXvaFbAFnAJ2Est+LGSFaLCVuDN3NzOELS+x /e0c5gmMgrOQ7JiFpGwWkrIFjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJTSjcx gsKaU5J/B+O3g0qHGAU4GJV4eD9s/h4ixJpYVlyZe4hRkoNJSZQ32PhHiBBfUn5KZUZicUZ8 UWlOavEhRgkOZiUR3nwtoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeH kgSvaBBQo2BRanpqRVpmTglCmomDE2Q4D9BwRZAa3uKCxNzizHSI/ClGRSlx3v+BQAkBkERG aR5cLyztvGIUB3pFmHcxSDsPMGXBdb8CGswENFhLDGxwSSJCSqqBMbNkiWHHYtXcQxeTYjaV 3twr9eFiK3/N9AmGd3vdxIwZo7p8o5MmLZv4W8fKKe5pgKDZhEfb7/N/2CteFZGk/kHbVFHD afmVR3EqWxzXRNZyn2M/dmpaxr08I/0TjHdDSuuWyG3lWiXHMXfBuuR/f2W9H/pe+/El7ulk kQ9GM1zPei5dNkVBTomlOCPRUIu5qDgRAFJR41IWAwAA Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:59:41 -0000 Right, but do we need to say that in Dyn-Reg? That's really more of a problem for the protocol using the keys, not the one registering it for use. -- Justin On 3/5/2015 7:58 AM, John Bradley wrote: > I am ok with saying that the JWK must have keyed if there is more than one key and it SHOULD if there is only one. > > Sent from my iPhone > >> On Mar 5, 2015, at 1:43 PM, Hannes Tschofenig wrote: >> >> Hi John, >> >> that's a good idea. However, the dynamic client registration should >> state that the "kid" parameter is used and must be included in the JWK >> (since the kid is an optional parameter). >> >> The key name is then the 'kid' plus the client id since the value of the >> kid is not unique by itself. >> >> Ciao >> Hannes >> >>> On 03/05/2015 12:54 PM, John Bradley wrote: >>> For signing authentication requests you include the keyid in the JWT, and the AS looks in the JWKS to find the correct key if there is more than one. >>> >>> I don't think that is a problem >>> >>> What we probably need to do is pass a keyid in the request if there is more than one signing key registered for the client. >>> >>> John B. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Mar 5 05:00:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504E21A01A9 for ; Thu, 5 Mar 2015 05:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 d3adE_HJYRuU for ; Thu, 5 Mar 2015 05:00:19 -0800 (PST) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.41]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F361A1A02 for ; Thu, 5 Mar 2015 05:00:18 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MXIGf-1Y028o0lqX-00WHmT; Thu, 05 Mar 2015 14:00:15 +0100 Message-ID: <54F8535D.5080206@gmx.net> Date: Thu, 05 Mar 2015 14:00:13 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Bradley References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net> <54F84F69.2090408@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IQCiEC62qpNx8ND19LtlfpVDIIqj3FvHB" X-Provags-ID: V03:K0:yLmSMrEZ/yOZ+LstgxhyCHRR/qVM8H9vVr7n4+uhvyJR40vj/JG efxbCu+rLjinpNPWM4s2N0lFhAXWTTm9xYvsOKrCgEe5OMZ/GCrQK4Y9cIcqLngZCRK0/lp 2WAgjRoZnBw3NBjwkRypN21qpKScJ6pxCJkYXaUI0AmleIg6dYG1AePo3aEsSbfAj5H36Rh rgGejcuyB0QthTm4XOl8w== X-UI-Out-Filterresults: junk:10; Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:00:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IQCiEC62qpNx8ND19LtlfpVDIIqj3FvHB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In context of we then need to differentiate the case where the client wants to have the server attach the already stored key vs. the case where the client wants to create a new key regardless whether there is one stored or not. Does that make sense? On 03/05/2015 01:58 PM, John Bradley wrote: > I am ok with saying that the JWK must have keyed if there is more than = one key and it SHOULD if there is only one.=20 --IQCiEC62qpNx8ND19LtlfpVDIIqj3FvHB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+FNdAAoJEGhJURNOOiAtTQ0IAJNGJReC6TEtHtGsCXByhDv5 g9t6IEkBYEWsqmoX8XvBqWM4RtDmepSWqxdJmt+/MLMEUOyu/xh5bDU++v2w9i1u Bk+7U5u/QextlmjvuZEmDY4A+QatHRcRE/VJuAmppVOCCDV5T0SjtX8DlpUCdXEW CtBW/rvqaTukLZJCZqtLXcbs2SJIu9t0SYuzgHpr3+wJ3L8Te3Z9Sy+CBUGBYWt7 nQCiAb9qk8oD1bM9gRg+PzW8UOVR+tpCSpcDlQrXqGu5NyeyFQUzqD1kpIfyZ6UD T8TrKvDeLXwXbZVhS1/pUdAglOZpDvh/vPzYrgbXdWVwSR5ko+Mm7R5QTTMASxU= =bvp8 -----END PGP SIGNATURE----- --IQCiEC62qpNx8ND19LtlfpVDIIqj3FvHB-- From nobody Thu Mar 5 05:00:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985A71A0318 for ; Thu, 5 Mar 2015 05:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 YQqWeNYSYcOK for ; Thu, 5 Mar 2015 05:00:50 -0800 (PST) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337601A01A9 for ; Thu, 5 Mar 2015 05:00:50 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Mbxdm-1YDUPQ2oIo-00JJtG; Thu, 05 Mar 2015 14:00:46 +0100 Message-ID: <54F8537D.5010309@gmx.net> Date: Thu, 05 Mar 2015 14:00:45 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Justin Richer , John Bradley References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net> <54F84F69.2090408@gmx.net> <54F8532F.7000501@mit.edu> In-Reply-To: <54F8532F.7000501@mit.edu> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SGSQQ2AqeqIf3kAW34mwuJxE7Gi4L7pO2" X-Provags-ID: V03:K0:TV1ZSVg1XwB4Gs+wtVMQTvBnSwyaBA9M9r0lTA2tdzhQ8ImgdK1 iMCyfw3/GsTftpMd3rhLj58mje6yriYdVz4aDJrLkF/WNfMdWB2GEp+HF4HoKPYgBd8qkKl VclKBXmj8tfUOotSGb63eMows9QZc6v+Z3D61zOvBbszVAkDeII99PojBkHf/iM9rIfCwCV J8Nm4GtDYOKgL7xgdQQ0w== X-UI-Out-Filterresults: junk:10; Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:00:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SGSQQ2AqeqIf3kAW34mwuJxE7Gi4L7pO2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree and this can be done in AUTH48. On 03/05/2015 01:59 PM, Justin Richer wrote: > Right, but do we need to say that in Dyn-Reg? That's really more of a > problem for the protocol using the keys, not the one registering it for= > use. --SGSQQ2AqeqIf3kAW34mwuJxE7Gi4L7pO2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+FN9AAoJEGhJURNOOiAt/YwH/RfXmVzETyWO3RRtPezuL2p+ aVx95C2pwnNv2i/KD5Xo7rlYphdEZ13fNk/i1LEgS6kTQZPnqvcy2aT8SEnXya4W 7kbqx/rp03uTGg8ia4pzLCg1G4xG5ItTEQX0fAzdQwGSboxG3WQp28fqq203/+Tp MUkih5qh4V1KTwckB0CGzKQ/pYye8ocuCqfglSdbaWPRumV+ZbLy7j60kDpQuQ4y BRwO9H/4+r66+wOLOSkfh824dtQPiPndIoHPvgbayiEQWFdRnQKvP7rSvjjB3eha whDJOOroREIpdmYNKqZAStm/XMtnAvtktdNmzdTrNk8Mgl0QXDETS/Uo5U5NUe8= =tCP1 -----END PGP SIGNATURE----- --SGSQQ2AqeqIf3kAW34mwuJxE7Gi4L7pO2-- From nobody Thu Mar 5 05:01:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9045F1A89A6 for ; Thu, 5 Mar 2015 05:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 22kCQyCOeI0c for ; Thu, 5 Mar 2015 05:01:32 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (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 D14071A01A9 for ; Thu, 5 Mar 2015 05:01:31 -0800 (PST) Received: by wggx13 with SMTP id x13so13059247wgg.4 for ; Thu, 05 Mar 2015 05:01:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+WF0dePm5HbhXV2DCpxkvUJb58fVnd4LyQLQXcGTj0U=; b=dbhFykclso6MN41m/P0F7bQKWwWtGX5b99RGauCg+D28nPKGt3FRVYTowNf1C3meTX wbqgIpsmt22+zrD1Ukpk6q3YxO+bcLjNKbec1tNuARjBDgTa1whzcia+GzDoKV4OnqOz azhZDKYxN4H6q4pMVBCBa3tczlH6c9iEZ/8bs+tc1Gym6BmA9/p5myAq1ArXQMbcA+02 jqXVafts6aYo0W51II6aFgKZWouwPZiiHyGArX+f10zG20+RlHXgV0IevKD0dvGjYJVM hfFOhRX2tKUSBjQVfGTY14vzWg89ALbpI7qCCvvppdvQ7KnIL1YF83dNb1/UsxH5Duye RQwA== X-Gm-Message-State: ALoCoQlEk3K3ntvbbh+PGvyn//7Y0ULAz2yNAG3bhLct8mTUlR3PT/2BMDa1pt8QgeneGUqZPN6t X-Received: by 10.180.94.199 with SMTP id de7mr3375205wib.53.1425560490520; Thu, 05 Mar 2015 05:01:30 -0800 (PST) Received: from [192.168.43.33] ([95.131.169.235]) by mx.google.com with ESMTPSA id e2sm10418785wjy.46.2015.03.05.05.01.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 05:01:29 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-84394C48-75A6-4510-9BA5-688B4D4D378D Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (12B466) In-Reply-To: <54F84B3D.1090401@mit.edu> Date: Thu, 5 Mar 2015 13:48:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: <9B6A57FD-4D82-4475-B2BE-6EC87D235754@ve7jtb.com> References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F84B3D.1090401@mit.edu> To: Justin Richer Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:01:37 -0000 --Apple-Mail-84394C48-75A6-4510-9BA5-688B4D4D378D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A middle ground, that perhaps no one will like is registering application s= pecific claims in the JWT registry, but pretending them with a app namespac= e.=20 Eg Int:active That prevents people from stepping on each other with short names, and give= s a central place to look them up, without requiring all all alls to unders= tand all claims.=20 John B.=20 Sent from my iPhone > On Mar 5, 2015, at 1:25 PM, Justin Richer wrote: >=20 > I'm OK with a separate registry, my only question is whether or not there'= s a way to correlate and coordinate the values of the two registries. The co= ncern with importing the JWT claims directly into introspection's response w= as that we'd potentially be stepping on an existing namespace. In practice, I= don't think that's a concern, but I can see the argument. If we establish a= n introspection response registry, how do we continue to deconflict with the= JWT registry? >=20 > -- Justin >=20 >> On 3/5/2015 2:36 AM, Mike Jones wrote: >> It sounds to me like you're making a good argument for this spec to have i= ts own registry. Registries are easy to establish and use. >> From: Justin Richer >> Sent: =E2=80=8E3/=E2=80=8E4/=E2=80=8E2015 6:43 PM >> To: Mike Jones; Hannes Tschofenig >> Cc: >> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "= Claims" >>=20 >> I'm actually fine with keeping the introspection-specific elements out of= the registry (see my note on "active" and how it doesn't fit in JWT below),= but I do not want to give up the short names. The short names are already i= n production, especially "active", which is well understood and used in prac= tice today, and has been for years[1]. Changing this would fundamentally bre= ak all existing implementations for no good reason. I'm slightly more OK wit= h changing "user_id" to "username", since that's not as widely deployed to m= y knowledge (other implementers, please pipe up if I'm mistaken), and I'm we= ll familiar with "preffered_username" in OIDC because I'm the one that put i= t in there [2]. :) While I prefer to leave it be at this stage, I think this= is a less destructive change than "active", "scope", or "client_id" would b= e.=20 >>=20 >> For background to my stance regarding the registry: several revisions (an= d years) ago, the introspection draft re-defined several fields that overlap= ped with JWT and we were asked to correlate the two. Originally, we simply h= ad a pointer to re-use the JWT claims as defined, and stacked our own claims= on top. Later, we were asked to outright merge them, which is what we have r= ight now. If the WG wants to back off that last change to the middle state -= - where we re-use the JWT registry but don't write to it -- I'm very happy w= ith that result and can work that (back) into the next draft. >>=20 >> Though it does point out something strange about the standards process th= at we're running into here: JWT needed a place to register bits of metadata a= bout a token, so it created one. This became the "JWT registry", and now it'= s got hangings of being "JWT-specific". When introspection came along with a= need to talk about much the same kind of information, it makes sense to re-= use the existing items but also that there would be things that are introspe= ction-specific.=20 >>=20 >> -- Justin >>=20 >> [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 >> [2] https://bitbucket.org/openid/connect/issue/584/messages-username-clai= m >>=20 >>> On 3/4/2015 6:28 PM, Mike Jones wrote: >>> I have severe concerns with this approach. It=E2=80=99s not appropriate= to register arbitrary JSON object member names as JWT claim names =E2=80=93= especially when the JSON object member names are not even being used as JWT= claim names. Please do not do this, as it would needlessly pollute the JWT= claim name namespace with registered names that are application specific. >>> =20 >>> Secondarily, I have concerns about these names and suggestions for how t= o address them. >>> =20 >>> =E2=80=9Cactive=E2=80=9D =E2=80=93 This claim is not presently adequatel= y defined. And its definition will of necessity be specific to the introspe= ction application. Therefore, it should not be registered as a general JWT c= laim name. A name I would be comfortable with for this concept would be urn= :ietf:params:oauth:introspection:active, since it makes it clear what applic= ation the name is used with. >>> =20 >>> =E2=80=9Cuser_id=E2=80=9D =E2=80=93 The concept you=E2=80=99re describin= g is almost universally called =E2=80=9Cusername=E2=80=9D. User ID is typic= ally the numeric account identifier (carried in the =E2=80=9Csub=E2=80=9D cl= aim in a JWT), and so is not the right name for this. Compare it to the pre= ferred_username claim in OpenID Connect. Please change this either to =E2=80= =9Cusername=E2=80=9D or urn:ietf:params:oauth:introspection:username. >>> =20 >>> =E2=80=9Ctoken_type=E2=80=9D =E2=80=93 While this is well-defined, the u= sage is fairly specific to this application. Again, adding the urn:ietf:par= ams:oauth:introspection: name prefix would address this issue. >>> =20 >>> If you give up registering these names in the JWT Claims registry, I=E2=80= =99m OK with you using short names. But if you want them to live alongside o= ther JWT claim names, please include the urn:ietf:params:oauth:introspection= : in lieu of registration. >>> =20 >>> Thank you, >>> -- Mike >>> =20 >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer >>> Sent: Wednesday, March 04, 2015 1:46 PM >>> To: Hannes Tschofenig >>> Cc: >>> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "= Claims" >>> =20 >>> Hi Hannes, thanks for the feedback. Responses inline. >>> =20 >>> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig wrote: >>> =20 >>> Hi Justin, Hi all, >>>=20 >>> in OAuth we provide two ways for a resource server to make an >>> authorization decision. >>>=20 >>> 1) The resource server receives a self-contained token that contains all= >>> the necessary information to make a local authorization decision. With >>> the JWT we have created such a standardized information and data model. >>>=20 >>> 2) With an access request from a client the resource server asks the >>> authorization server for "help". The authorization server provides >>> information that help make the authorization decision. This is the token= >>> introspection approach. >>>=20 >>> I believe the two approaches need to be aligned with regard to the >>> information and the data model. Since both documents already use JSON as= >>> a way to encode information (=3Ddata model) and almost have an identical= >>> information model (the data that is being passed around). >>>=20 >>> What needs to be done? >>>=20 >>> * Use the term 'claims' in both documents. >>> * Use the same registry (i.e., the registry established with the JWT). >>> * Register the newly defined claims from the token introspection >>> document in the claims registry. >>>=20 >>> =20 >>> We=E2=80=99ve already done this in the latest draft. Or at least, that=E2= =80=99s the intent of the current text =E2=80=94 the registry is referenced a= nd the new claims are registered. Can you specifically point to places where= this needs to be improved upon? >>>=20 >>>=20 >>> Then, I have a few comments on the new claims that are proposed: >>>=20 >>> Here is the definition of the 'active' claim: >>>=20 >>> active >>> REQUIRED. Boolean indicator of whether or not the presented token >>> is currently active. The authorization server determines whether >>> and when a given token is in an active state. >>>=20 >>> This claim is not well-defined. You need to explain what "active" means.= >>> It could, for example, mean that the token is not yet expired. Then, >>> there is of course the question why you are not returning the 'exp' >>> claim together with the 'nbf' claim. >>> =20 >>> The definition of =E2=80=9Cactive=E2=80=9D is really up to the authoriza= tion server, and I=E2=80=99ve yet to hear from an actual implementor who=E2=80= =99s confused by this definition. When you=E2=80=99re the one issuing the to= kens, you know what an =E2=80=9Cactive=E2=80=9D token means to you. Still, p= erhaps we can be even more explicit, such as: >>> =20 >>> =20 >>> active >>> REQUIRED. Boolean indicator of whether or not the presented token is c= urrently active. The specifics of a token=E2=80=99s active state will vary d= epending on the implementation of the authorization server, but generally th= is will indicate that a given token has been issued by this authorization se= rver, has not been revoked by the resource owner, and is within its given ti= me window of validity (e.g. not expired).=20 >>> =20 >>> Also, this is one of the places where the overlap between JWT and intros= pection claims don=E2=80=99t make sense. It doesn=E2=80=99t make any sense f= or a JWT to carry an =E2=80=9Cactive=E2=80=9D claim at all. Why would you ha= ve a JWT claim to be anything but active? We should register it with the JWT= registry to avoid name collisions, but there=E2=80=99s nothing in the JWT r= egistry that says =E2=80=9Cdon=E2=80=99t use this inside of a JWT=E2=80=9D. D= o you have any advice on how to address this? >>>=20 >>>=20 >>>=20 >>> client_id: What is the resource server going to do with the client_id? >>> What authorization decision could it make? >>> =20 >>> Whatever it wants to. If an RS can figure out something from the client_= id, why not let it? The client_id is a piece of information about the contex= t of the issuance of the token, and a common enough OAuth value for decision= making.=20 >>>=20 >>>=20 >>> I have a couple of reactions when I read the 'user_id' claim: >>> - I believe the inclusion of a user id field in the = response could >>> lead to further confusion regarding OAuth access token usage for >>> authentication. >>> =20 >>> This isn=E2=80=99t any different from having a userinfo-endpoint equival= ent (like social graph or twitter API) and it=E2=80=99s got the same trouble= .=20 >>>=20 >>>=20 >>>=20 >>> - Since you define it as a human readable identifier I am wondering >>> whether you want to say something about the usage. Here it seems that it= >>> might be used for displaying something on a webpage rather than making >>> an authorization decision but I might well be wrong. >>> =20 >>> We added in =E2=80=9Cuser_id=E2=80=9D to our implementation due to devel= oper demand =E2=80=94 they wanted a username associated with the return valu= e, but to leave the =E2=80=9Csub=E2=80=9D value the same as that defined by O= penID Connect. Note that this is in an environment where the username is a k= nown quantity, and they=E2=80=99re not trying to do cross-domain authenticat= ion. They just want to know whose token this was so they can figure out whos= e data to return. It=E2=80=99s not used for display, but I tried to make the= definition in contrast to the machine-facing =E2=80=9Csub=E2=80=9D value. >>>=20 >>>=20 >>>=20 >>> - I am missing a discussion about the privacy implications of it. >>> While there is a privacy consideration section I am wondering what >>> controls the release of this sensitive information from the >>> authorization server to the resource server. While in some cases the two= >>> parties might belong to the same organization but in other cases that >>> may not necessarily be true. >>> =20 >>> You=E2=80=99re correct, this is currently missing and I=E2=80=99ll add t= hat in. >>>=20 >>>=20 >>>=20 >>> - In terms of the information exchanged about the user I am curious >>> about the usefulness of including other information as well, such as the= >>> info that is included in an id token (see >>> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this >>> has nothing to do with the ID token concept and the information carried >>> within it then I would add that remark. >>> =20 >>> =20 >>> You could introspect an ID token if you wanted to, but it=E2=80=99s usua= lly easier to just parse it yourself because it=E2=80=99s self-contained. Th= e ID Token also extends JWT, so there=E2=80=99s nothing stopping you from re= turning those claims as well. However, note that the audience of the ID toke= n is the OAuth *client* whereas the targeted user of the = introspection endpoint is the *protected resource*. The PR isn=E2=80=99t go= ing to see the ID Token most of the time, and the client=E2=80=99s not going= to need to (or be able to) introspect its tokens most of the time, so in pr= actice there=E2=80=99s not really any overlap. >>> =20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>>=20 >>> Ciao >>> Hannes >>>=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 --Apple-Mail-84394C48-75A6-4510-9BA5-688B4D4D378D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
A middle ground,  that perhaps no= one will like is registering application specific claims in the JWT registr= y,  but pretending them with a app namespace. 

Eg
Int:active

That prevents people f= rom stepping on each other with short names,  and gives a central place= to look them up,  without requiring all all alls to understand all cla= ims. 

John B. 

Sent from my= iPhone

On Mar 5, 2015, at 1:25 PM, Justin Richer <jricher@mit.edu> wrote:

=20 =20 =20 I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry?

 -- Justin

On 3/5/2015 2:36 AM, Mike Jones wrote:
It sounds to me like you're making a good argument for this spec to have its own registry.  Registries are easy to establish and use.
From: Justin Richer
Sent: =E2=80=8E3/=E2=80=8E4/=E2=80=8E2015 6:43 PM=
To: Mike Jones; Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on "active" and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially "active", which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing "user_id" to "username", since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with "preffered_username" in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than "active", "scope", or "client_id" would be.

For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft.

Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the "JWT registry", and now it's got hangings of being "JWT-specific". When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific.

 -- Justin

[1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03
[2] = https://bitbucket.org/openid/connect/issue/584/messages-username-claim
On 3/4/2015 6:28 PM, Mike Jones wrote:

I have severe concerns with this approach.  It=E2=80=99s not appropriate to register arb= itrary JSON object member names as JWT claim names =E2=80=93 especi= ally when the JSON object member names are not even being used as JWT claim names.  Please do not do this,= as it would needlessly pollute the JWT claim name namespace with registered names that are application specific.

 

Secondarily, I have concerns about these names and suggestions for how to address them.

 

=E2=80=9Cactive=E2=80=9D =E2=80=93 This claim= is not presently adequately defined.  And its definition will of necessity be specific to the introspection application. = ; Therefore, it should not be registered as a general JWT claim name.  A name I would be comfortable with for thi= s concept would be urn:ietf:params:oauth:introspection:active, since it makes it clear what application the name is used with.

 

=E2=80=9Cuser_id=E2=80=9D =E2=80=93 The conce= pt you=E2=80=99re describing is almost universally called =E2=80=9Cusername=E2=80=9D.&nbs= p; User ID is typically the numeric account identifier (carried in the =E2=80=9Csub=E2=80=9D claim in a JWT), and so is not the rig= ht name for this.  Compare it to the preferred_username claim in OpenID Connect.  Please change this either to =E2=80=9C= username=E2=80=9D or urn:ietf:params:oauth:introspection:username.

 

=E2=80=9Ctoken_type=E2=80=9D =E2=80=93 While t= his is well-defined, the usage is fairly specific to this application.  Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue.

 

If you give up registering these names in the JWT Claims registry, I=E2=80=99m OK with you using short= names.  But if you want them to live alongside other JW= T claim names, please include the urn:ietf:params:oauth:introspection: in lieu of registration.

 

       &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp; Thank you,

       &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp; -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.= org] On Behalf Of Justin Richer
Sent: Wednesday, March 04, 2015 1:46 PM
To: Hannes Tschofenig
Cc: <oauth@ietf.org>
= Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

 

Hi Hannes, thanks for the feedback. Responses inline.

 

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

 

Hi= Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=3Ddata model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

* Use the term 'claims' in both documents.
* Use the same registry (i.e., the registry established with the JWT).
* Register the newly defined claims from the token introspection
document in the claims registry.

 

We=E2=80=99ve already done this in t= he latest draft. Or at least, that=E2=80=99s the intent of t= he current text =E2=80=94 the registry is referenced and th= e new claims are registered. Can you specifically point to places where this needs to be improved upon?



Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

  active
     REQUIRED.  Boolean in= dicator of whether or not the presented token
     is currently active.  = ;The authorization server determines whether
     and when a given token is i= n an active state.

This claim is not well-defined. You need to explain what "active" means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

 

The definition of =E2=80=9Cactive=E2= =80=9D is really up to the authorization server, and I=E2=80=99ve y= et to hear from an actual implementor who=E2=80=99s confuse= d by this definition. When you=E2=80=99re the one issuing the= tokens, you know what an =E2=80=9Cactive=E2=80=9D token m= eans to you. Still, perhaps we can be even more explicit, such as:

 

 

active

  REQUIRED. Boolean indicator of= whether or not the presented token is currently active. The specifics of a token=E2=80=99s active state wi= ll vary depending on the implementation of the authorization server, but generally this will indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g. not expired). 

 

Also, this is one of the places where the overlap between JWT and introspection claims don=E2=80=99t make sense. It doesn=E2=80=99t make= any sense for a JWT to carry an =E2=80=9Cactive=E2=80=9D claim at a= ll. Why would you have a JWT claim to be anything but active? We should register it with the JWT registry to avoid name collisions, but there=E2=80=99s nothing in= the JWT registry that says =E2=80=9Cdon=E2=80=99t use this i= nside of a JWT=E2=80=9D. Do you have any advice on how to address t= his?




client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

 

Whatever it wants to. If an RS can figure out something from the client_id, why not let it? The client_id is a piece of information about the context of the issuance of the token, and a common enough OAuth value for decision making. 



I have a couple of reactions when I read the 'user_id' claim:
 - I believe the inclusion of a user id field in th= e response could
lead to further confusion regarding OAuth access token usage for
authentication.

 

This isn=E2=80=99t any different fr= om having a userinfo-endpoint equivalent (like social graph or twitter API) and it=E2=80=99s got the same trouble. 




 - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

=

 

We added in =E2=80=9Cuser_id=E2=80=9D= to our implementation due to developer demand =E2=80=94 they wa= nted a username associated with the return value, but to leave the =E2=80=9Csub=E2=80=9D value the same as that d= efined by OpenID Connect. Note that this is in an environment where the username is a known quantity, and they=E2=80=99= re not trying to do cross-domain authentication. They just want to know whose token this was so they can figure out whose data to return. It=E2=80=99s not used f= or display, but I tried to make the definition in contrast to the machine-facing =E2=80=9Csub=E2=80=9D val= ue.




 - I am missing a discussion about the privacy implications of it.
While there is a privacy consideration section I am wondering what
controls the release of this sensitive information from the
authorization server to the resource server. While in some cases the two
parties might belong to the same organization but in other cases that
may not necessarily be true.

 

You=E2=80=99re correct, this is cur= rently missing and I=E2=80=99ll add that in.




 - In terms of the information exchanged about the user I am curious
about the usefulness of including other information as well, such as the
info that is included in an id token (see
http://openid.net/specs/openid-con= nect-core-1_0.html#IDToken). If this
has nothing to do with the ID token concept and the information carried
within it then I would add that remark.

 

 

You could introspect an ID token if you wanted to, but it=E2=80=99s usually easier to jus= t parse it yourself because it=E2=80=99s self-contained. T= he ID Token also extends JWT, so there=E2=80=99s nothing stopping you from returning those claims as well. However, note that the audience of the ID token is the OAuth *client* whereas the targeted user of the introspection endpoint is the *protected resource*. The PR isn=E2=80=99t going to see the ID Token most of t= he time, and the client=E2=80=99s not going to need to (or b= e able to) introspect its tokens most of the time, so in practice there=E2=80=99s not really any overlap.

 

 =E2=80=94 Justin




Ciao
Hannes

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

=

 



=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-84394C48-75A6-4510-9BA5-688B4D4D378D-- From nobody Thu Mar 5 05:02:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4511A1A02 for ; Thu, 5 Mar 2015 05:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7Q3szx-Wjyfa for ; Thu, 5 Mar 2015 05:02:39 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99CC1A0387 for ; Thu, 5 Mar 2015 05:02:38 -0800 (PST) X-AuditID: 12074423-f79066d0000058b8-04-54f853ecc4fc Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 93.8F.22712.CE358F45; Thu, 5 Mar 2015 08:02:36 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t25D2ZvE022322; Thu, 5 Mar 2015 08:02:35 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t25D2XKa031392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 08:02:34 -0500 Message-ID: <54F853E2.9030405@mit.edu> Date: Thu, 05 Mar 2015 08:02:26 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Bradley References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F84B3D.1090401@mit.edu> <9B6A57FD-4D82-4475-B2BE-6EC87D235754@ve7jtb.com> In-Reply-To: <9B6A57FD-4D82-4475-B2BE-6EC87D235754@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------030502010202000208050302" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6novsm+EeIwZ9z0hZLd95jtdg77ROL xcm3r9gsVt/9y+bA4rF40342jyVLfjJ5tO74y+5x+/ZGlgCWKC6blNSczLLUIn27BK6M/we2 shTc+MhU8brVq4Gx8wVjFyMnh4SAiUTj+b1MELaYxIV769m6GLk4hAQWM0l03O2FcjYwSsza cAHKucUksW7nP3aQFl4BNYkFW46DjWIRUJXY8G4xM4jNBmRPX9MCNlZUIEqi5083G0S9oMTJ mU9YQGwRARWJffseMYIMZRaYxCixeM1mVpCEsECAxIptJ1khtj1nkrj24zrYVE4BO4n3l04A TWUH6giTmF49gVFgFpKxs+ASIFFmATOJeZsfMkPY8hLNW2cD2RxAtprEslYlZOEFjGyrGGVT cqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxguPCRXkH45+DSocYBTgYlXh4Z2z8HiLE mlhWXJl7iFGSg0lJlDfY+EeIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHefC2gHG9KYmVValE+ TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBG9JEFCjYFFqempFWmZOCUKaiYMTZDgP 0HBFkBre4oLE3OLMdIj8KUZFKXHeHJCEAEgiozQPrheWtl4xigO9IsybBVLFA0x5cN2vgAYz AQ3WEgMbXJKIkJJqYHR579f2T+h/rNGOFVIZ7Guqfog9KD1kGLWsuuOD9G2rqk9vLO7HL0nI 9fDKtxZznn3GVOfG5SXFMQWds5qfvFPpOch+VvuBYkdxodrfLyJN3zcek65JuWdVNUvqbHz7 9w/PHaaYyD6N99x+58nmozef/Z67QE9zf10Tj0fPy+NNJ4R4065t267EUpyRaKjFXFScCADC N5O9NgMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:02:44 -0000 This is a multi-part message in MIME format. --------------030502010202000208050302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit And you're right that I *really* don't like this because it breaks existing implementations somewhat arbitrarily. Mike had suggested something similar. -- Justin On 3/5/2015 7:48 AM, John Bradley wrote: > A middle ground, that perhaps no one will like is registering > application specific claims in the JWT registry, but pretending them > with a app namespace. > > Eg > Int:active > > That prevents people from stepping on each other with short names, > and gives a central place to look them up, without requiring all all > alls to understand all claims. > > John B. > > Sent from my iPhone > > On Mar 5, 2015, at 1:25 PM, Justin Richer > wrote: > >> I'm OK with a separate registry, my only question is whether or not >> there's a way to correlate and coordinate the values of the two >> registries. The concern with importing the JWT claims directly into >> introspection's response was that we'd potentially be stepping on an >> existing namespace. In practice, I don't think that's a concern, but >> I can see the argument. If we establish an introspection response >> registry, how do we continue to deconflict with the JWT registry? >> >> -- Justin >> >> On 3/5/2015 2:36 AM, Mike Jones wrote: >>> It sounds to me like you're making a good argument for this spec to >>> have its own registry. Registries are easy to establish and use. >>> ------------------------------------------------------------------------ >>> From: Justin Richer >>> Sent: ‎3/‎4/‎2015 6:43 PM >>> To: Mike Jones ; Hannes >>> Tschofenig >>> Cc: >>> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token >>> Introspection "Claims" >>> >>> I'm actually fine with keeping the introspection-specific elements >>> out of the registry (see my note on "active" and how it doesn't fit >>> in JWT below), but I do not want to give up the short names. The >>> short names are already in production, especially "active", which is >>> well understood and used in practice today, and has been for >>> years[1]. Changing this would fundamentally break all existing >>> implementations for no good reason. I'm slightly more OK with >>> changing "user_id" to "username", since that's not as widely >>> deployed to my knowledge (other implementers, please pipe up if I'm >>> mistaken), and I'm well familiar with "preffered_username" in OIDC >>> because I'm the one that put it in there [2]. :) While I prefer to >>> leave it be at this stage, I think this is a less destructive change >>> than "active", "scope", or "client_id" would be. >>> >>> For background to my stance regarding the registry: several >>> revisions (and years) ago, the introspection draft re-defined >>> several fields that overlapped with JWT and we were asked to >>> correlate the two. Originally, we simply had a pointer to re-use the >>> JWT claims as defined, and stacked our own claims on top. Later, we >>> were asked to outright merge them, which is what we have right now. >>> If the WG wants to back off that last change to the middle state -- >>> where we re-use the JWT registry but don't write to it -- I'm very >>> happy with that result and can work that (back) into the next draft. >>> >>> Though it does point out something strange about the standards >>> process that we're running into here: JWT needed a place to register >>> bits of metadata about a token, so it created one. This became the >>> "JWT registry", and now it's got hangings of being "JWT-specific". >>> When introspection came along with a need to talk about much the >>> same kind of information, it makes sense to re-use the existing >>> items but also that there would be things that are >>> introspection-specific. >>> >>> -- Justin >>> >>> [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 >>> [2] >>> https://bitbucket.org/openid/connect/issue/584/messages-username-claim >>> >>> On 3/4/2015 6:28 PM, Mike Jones wrote: >>>> >>>> I have severe concerns with this approach. It’s not appropriate to >>>> register arbitrary JSON object member names as JWT claim names – >>>> especially when the JSON object member names are not even being >>>> used as JWT claim names. *Please do not do this*, as it would >>>> needlessly pollute the JWT claim name namespace with registered >>>> names that are application specific. >>>> >>>> Secondarily, I have concerns about these names and suggestions for >>>> how to address them. >>>> >>>> “active” – This claim is not presently adequately defined. And its >>>> definition will of necessity be specific to the introspection >>>> application. Therefore, it should not be registered as a general >>>> JWT claim name. A name I would be comfortable with for this >>>> concept would be urn:ietf:params:oauth:introspection:active, since >>>> it makes it clear what application the name is used with. >>>> >>>> “user_id” – The concept you’re describing is almost universally >>>> called “username”. User ID is typically the numeric account >>>> identifier (carried in the “sub” claim in a JWT), and so is not the >>>> right name for this. Compare it to the preferred_username claim in >>>> OpenID Connect. Please change this either to “username” or >>>> urn:ietf:params:oauth:introspection:username. >>>> >>>> “token_type” – While this is well-defined, the usage is fairly >>>> specific to this application. Again, adding the >>>> urn:ietf:params:oauth:introspection: name prefix would address this >>>> issue. >>>> >>>> If you give up registering these names in the JWT Claims registry, >>>> I’m OK with you using short names. But if you want them to live >>>> alongside other JWT claim names, please include the >>>> urn:ietf:params:oauth:introspection: in lieu of registration. >>>> >>>> Thank you, >>>> >>>> -- Mike >>>> >>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin >>>> Richer >>>> *Sent:* Wednesday, March 04, 2015 1:46 PM >>>> *To:* Hannes Tschofenig >>>> *Cc:* >>>> *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token >>>> Introspection "Claims" >>>> >>>> Hi Hannes, thanks for the feedback. Responses inline. >>>> >>>> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig >>>> > >>>> wrote: >>>> >>>> Hi Justin, Hi all, >>>> >>>> in OAuth we provide two ways for a resource server to make an >>>> authorization decision. >>>> >>>> 1) The resource server receives a self-contained token that >>>> contains all >>>> the necessary information to make a local authorization >>>> decision. With >>>> the JWT we have created such a standardized information and >>>> data model. >>>> >>>> 2) With an access request from a client the resource server >>>> asks the >>>> authorization server for "help". The authorization server provides >>>> information that help make the authorization decision. This is >>>> the token >>>> introspection approach. >>>> >>>> I believe the two approaches need to be aligned with regard to the >>>> information and the data model. Since both documents already >>>> use JSON as >>>> a way to encode information (=data model) and almost have an >>>> identical >>>> information model (the data that is being passed around). >>>> >>>> What needs to be done? >>>> >>>> * Use the term 'claims' in both documents. >>>> * Use the same registry (i.e., the registry established with >>>> the JWT). >>>> * Register the newly defined claims from the token introspection >>>> document in the claims registry. >>>> >>>> We’ve already done this in the latest draft. Or at least, that’s >>>> the intent of the current text — the registry is referenced and the >>>> new claims are registered. Can you specifically point to places >>>> where this needs to be improved upon? >>>> >>>> >>>> >>>> Then, I have a few comments on the new claims that are proposed: >>>> >>>> Here is the definition of the 'active' claim: >>>> >>>> active >>>> REQUIRED. Boolean indicator of whether or not the presented token >>>> is currently active. The authorization server determines whether >>>> and when a given token is in an active state. >>>> >>>> This claim is not well-defined. You need to explain what "active" >>>> means. >>>> It could, for example, mean that the token is not yet expired. Then, >>>> there is of course the question why you are not returning the 'exp' >>>> claim together with the 'nbf' claim. >>>> >>>> The definition of “active” is really up to the authorization >>>> server, and I’ve yet to hear from an actual implementor who’s >>>> confused by this definition. When you’re the one issuing the >>>> tokens, you know what an “active” token means to you. Still, >>>> perhaps we can be even more explicit, such as: >>>> >>>> active >>>> >>>> REQUIRED. Boolean indicator of whether or not the presented >>>> token is currently active. The specifics of a token’s active >>>> state will vary depending on the implementation of the >>>> authorization server, but generally this will indicate that a >>>> given token has been issued by this authorization server, has >>>> not been revoked by the resource owner, and is within its given >>>> time window of validity (e.g. not expired). >>>> >>>> Also, this is one of the places where the overlap between JWT and >>>> introspection claims don’t make sense. It doesn’t make any sense >>>> for a JWT to carry an “active” claim at all. Why would you have a >>>> JWT claim to be anything but active? We should register it with the >>>> JWT registry to avoid name collisions, but there’s nothing in the >>>> JWT registry that says “don’t use this inside of a JWT”. Do you >>>> have any advice on how to address this? >>>> >>>> >>>> >>>> >>>> client_id: What is the resource server going to do with the client_id? >>>> What authorization decision could it make? >>>> >>>> Whatever it wants to. If an RS can figure out something from the >>>> client_id, why not let it? The client_id is a piece of information >>>> about the context of the issuance of the token, and a common enough >>>> OAuth value for decision making. >>>> >>>> >>>> >>>> I have a couple of reactions when I read the 'user_id' claim: >>>> - I believe the inclusion of a user id field in the response could >>>> lead to further confusion regarding OAuth access token usage for >>>> authentication. >>>> >>>> This isn’t any different from having a userinfo-endpoint equivalent >>>> (like social graph or twitter API) and it’s got the same trouble. >>>> >>>> >>>> >>>> >>>> - Since you define it as a human readable identifier I am wondering >>>> whether you want to say something about the usage. Here it seems >>>> that it >>>> might be used for displaying something on a webpage rather than making >>>> an authorization decision but I might well be wrong. >>>> >>>> We added in “user_id” to our implementation due to developer demand >>>> — they wanted a username associated with the return value, but to >>>> leave the “sub” value the same as that defined by OpenID Connect. >>>> Note that this is in an environment where the username is a known >>>> quantity, and they’re not trying to do cross-domain authentication. >>>> They just want to know whose token this was so they can figure out >>>> whose data to return. It’s not used for display, but I tried to >>>> make the definition in contrast to the machine-facing “sub” value. >>>> >>>> >>>> >>>> >>>> - I am missing a discussion about the privacy implications of it. >>>> While there is a privacy consideration section I am wondering what >>>> controls the release of this sensitive information from the >>>> authorization server to the resource server. While in some cases >>>> the two >>>> parties might belong to the same organization but in other cases that >>>> may not necessarily be true. >>>> >>>> You’re correct, this is currently missing and I’ll add that in. >>>> >>>> >>>> >>>> >>>> - In terms of the information exchanged about the user I am curious >>>> about the usefulness of including other information as well, such >>>> as the >>>> info that is included in an id token (see >>>> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this >>>> has nothing to do with the ID token concept and the information carried >>>> within it then I would add that remark. >>>> >>>> You could introspect an ID token if you wanted to, but it’s usually >>>> easier to just parse it yourself because it’s self-contained. The >>>> ID Token also extends JWT, so there’s nothing stopping you from >>>> returning those claims as well. However, note that the audience of >>>> the ID token is the OAuth *client* whereas the targeted user of the >>>> introspection endpoint is the *protected resource*. The PR isn’t >>>> going to see the ID Token most of the time, and the client’s not >>>> going to need to (or be able to) introspect its tokens most of the >>>> time, so in practice there’s not really any overlap. >>>> >>>> — Justin >>>> >>>> >>>> >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> 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 --------------030502010202000208050302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit And you're right that I *really* don't like this because it breaks existing implementations somewhat arbitrarily. Mike had suggested something similar.

 -- Justin

On 3/5/2015 7:48 AM, John Bradley wrote:
A middle ground,  that perhaps no one will like is registering application specific claims in the JWT registry,  but pretending them with a app namespace. 

Eg
Int:active

That prevents people from stepping on each other with short names,  and gives a central place to look them up,  without requiring all all alls to understand all claims. 

John B. 

Sent from my iPhone

On Mar 5, 2015, at 1:25 PM, Justin Richer <jricher@mit.edu> wrote:

I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry?

 -- Justin

On 3/5/2015 2:36 AM, Mike Jones wrote:
It sounds to me like you're making a good argument for this spec to have its own registry.  Registries are easy to establish and use.
From: Justin Richer
Sent: ‎3/‎4/‎2015 6:43 PM
To: Mike Jones; Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on "active" and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially "active", which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing "user_id" to "username", since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with "preffered_username" in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than "active", "scope", or "client_id" would be.

For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft.

Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the "JWT registry", and now it's got hangings of being "JWT-specific". When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific.

 -- Justin

[1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03
[2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim

On 3/4/2015 6:28 PM, Mike Jones wrote:

I have severe concerns with this approach.  It’s not appropriate to register arbitrary JSON object member names as JWT claim names – especially when the JSON object member names are not even being used as JWT claim names.  Please do not do this, as it would needlessly pollute the JWT claim name namespace with registered names that are application specific.

 

Secondarily, I have concerns about these names and suggestions for how to address them.

 

“active” – This claim is not presently adequately defined.  And its definition will of necessity be specific to the introspection application.  Therefore, it should not be registered as a general JWT claim name.  A name I would be comfortable with for this concept would be urn:ietf:params:oauth:introspection:active, since it makes it clear what application the name is used with.

 

“user_id” – The concept you’re describing is almost universally called “username”.  User ID is typically the numeric account identifier (carried in the “sub” claim in a JWT), and so is not the right name for this.  Compare it to the preferred_username claim in OpenID Connect.  Please change this either to “username” or urn:ietf:params:oauth:introspection:username.

 

“token_type” – While this is well-defined, the usage is fairly specific to this application.  Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue.

 

If you give up registering these names in the JWT Claims registry, I’m OK with you using short names.  But if you want them to live alongside other JWT claim names, please include the urn:ietf:params:oauth:introspection: in lieu of registration.

 

                                                            Thank you,

                                                            -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, March 04, 2015 1:46 PM
To: Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

 

Hi Hannes, thanks for the feedback. Responses inline.

 

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

 

Hi Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=data model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

* Use the term 'claims' in both documents.
* Use the same registry (i.e., the registry established with the JWT).
* Register the newly defined claims from the token introspection
document in the claims registry.

 

We’ve already done this in the latest draft. Or at least, that’s the intent of the current text — the registry is referenced and the new claims are registered. Can you specifically point to places where this needs to be improved upon?



Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

  active
     REQUIRED.  Boolean indicator of whether or not the presented token
     is currently active.  The authorization server determines whether
     and when a given token is in an active state.

This claim is not well-defined. You need to explain what "active" means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

 

The definition of “active” is really up to the authorization server, and I’ve yet to hear from an actual implementor who’s confused by this definition. When you’re the one issuing the tokens, you know what an “active” token means to you. Still, perhaps we can be even more explicit, such as:

 

 

active

  REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token’s active state will vary depending on the implementation of the authorization server, but generally this will indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g. not expired). 

 

Also, this is one of the places where the overlap between JWT and introspection claims don’t make sense. It doesn’t make any sense for a JWT to carry an “active” claim at all. Why would you have a JWT claim to be anything but active? We should register it with the JWT registry to avoid name collisions, but there’s nothing in the JWT registry that says “don’t use this inside of a JWT”. Do you have any advice on how to address this?




client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

 

Whatever it wants to. If an RS can figure out something from the client_id, why not let it? The client_id is a piece of information about the context of the issuance of the token, and a common enough OAuth value for decision making. 



I have a couple of reactions when I read the 'user_id' claim:
 - I believe the inclusion of a user id field in the response could
lead to further confusion regarding OAuth access token usage for
authentication.

 

This isn’t any different from having a userinfo-endpoint equivalent (like social graph or twitter API) and it’s got the same trouble. 




 - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

 

We added in “user_id” to our implementation due to developer demand — they wanted a username associated with the return value, but to leave the “sub” value the same as that defined by OpenID Connect. Note that this is in an environment where the username is a known quantity, and they’re not trying to do cross-domain authentication. They just want to know whose token this was so they can figure out whose data to return. It’s not used for display, but I tried to make the definition in contrast to the machine-facing “sub” value.




 - I am missing a discussion about the privacy implications of it.
While there is a privacy consideration section I am wondering what
controls the release of this sensitive information from the
authorization server to the resource server. While in some cases the two
parties might belong to the same organization but in other cases that
may not necessarily be true.

 

You’re correct, this is currently missing and I’ll add that in.




 - In terms of the information exchanged about the user I am curious
about the usefulness of including other information as well, such as the
info that is included in an id token (see
http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this
has nothing to do with the ID token concept and the information carried
within it then I would add that remark.

 

 

You could introspect an ID token if you wanted to, but it’s usually easier to just parse it yourself because it’s self-contained. The ID Token also extends JWT, so there’s nothing stopping you from returning those claims as well. However, note that the audience of the ID token is the OAuth *client* whereas the targeted user of the introspection endpoint is the *protected resource*. The PR isn’t going to see the ID Token most of the time, and the client’s not going to need to (or be able to) introspect its tokens most of the time, so in practice there’s not really any overlap.

 

 — Justin




Ciao
Hannes

_______________________________________________
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

--------------030502010202000208050302-- From nobody Thu Mar 5 05:04:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778AA1A01BA for ; Thu, 5 Mar 2015 05:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Y-DKj-guSlMp for ; Thu, 5 Mar 2015 05:04:31 -0800 (PST) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.40]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8136F1A01A9 for ; Thu, 5 Mar 2015 05:04:31 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LqE5k-1Xq1td1jiy-00dnWZ; Thu, 05 Mar 2015 14:04:29 +0100 Message-ID: <54F8545B.4010602@gmx.net> Date: Thu, 05 Mar 2015 14:04:27 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Bradley References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net> <54F84F69.2090408@gmx.net> In-Reply-To: <54F84F69.2090408@gmx.net> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PLUW15DTSWMSuwXwMNvm36bHfgHODLUBd" X-Provags-ID: V03:K0:kI2xXLkugIU+gxVyQ3Bq20kkmDlSkRsVaTTpmdMOZzivNqEKBf4 SuDAf3+klDAezl1I0ROdt2zEXF9h2HWyqXdWUUME4kR/aew9ZCp6fzvEcs9mR+RoE/JcNNz qZexntxu291iv70XslcuL4HYltpYNzgaJJ+81haajjcsyH8zodzkTcY5WF/hprsEqDDouFe y6vdM6PK2H1QatO8AnKqg== X-UI-Out-Filterresults: junk:10; Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:04:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PLUW15DTSWMSuwXwMNvm36bHfgHODLUBd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Actually, I am not sure my statement below is actually correct. We need to distinguish the case where the client id is unique per client software instance and when it isn't. If the client id is shared by multiple client software instances then how do we make sure that clients aren't uploading keys that either have no kid or have an kid that is not unique (since they don't know about the existence of other client instances or that other client instances have already uploaded a jwk with the same kid). Any idea how to address that problem? Ciao Hannes On 03/05/2015 01:43 PM, Hannes Tschofenig wrote: > Hi John, >=20 > that's a good idea. However, the dynamic client registration should > state that the "kid" parameter is used and must be included in the JWK > (since the kid is an optional parameter). >=20 > The key name is then the 'kid' plus the client id since the value of th= e > kid is not unique by itself. >=20 > Ciao > Hannes >=20 > On 03/05/2015 12:54 PM, John Bradley wrote: >> For signing authentication requests you include the keyid in the JWT, = and the AS looks in the JWKS to find the correct key if there is more tha= n one. >> >> I don't think that is a problem >> >> What we probably need to do is pass a keyid in the request if there is= more than one signing key registered for the client. >> >> John B. >=20 --PLUW15DTSWMSuwXwMNvm36bHfgHODLUBd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+FRbAAoJEGhJURNOOiAtKHMH/jUEiHXVdmD3NlNg+BY4sZ12 iy75t9MKOJyk0UxChovPwdrce6bV3Bym8/fDbUXZNnNzMwl3y+0+PuIRj0M3CoEK YETDOYEts+RwXdXuNbqmQHPIxfbnjTTDmT3SJSntPz6Z+anAgsw/jwD/BRLuBb6k URDb65yfXHl2qBZ6+EvmEM9s2s7eMAQm1iyLkUinxCY1O9A30r7IbnpLvAGUerah CsuOMLO9g3Mp66YugmzrPyWKpdPo0y6szpPAC8HqWY/jsDQ+ATMX+51Kx5yPQhdQ v0gkVGLDhFqSBQSjVx9nG9gmO35up4jL2UYCa7iQtdpUkIS8QgJyq+rkUPw1vuY= =gGax -----END PGP SIGNATURE----- --PLUW15DTSWMSuwXwMNvm36bHfgHODLUBd-- From nobody Thu Mar 5 05:15:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854E51B2A41 for ; Thu, 5 Mar 2015 05:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oTVIz2065Jcj for ; Thu, 5 Mar 2015 05:15:36 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CA51A1A38 for ; Thu, 5 Mar 2015 05:15:35 -0800 (PST) X-AuditID: 12074424-f79356d000004839-52-54f856f58960 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 89.1C.18489.6F658F45; Thu, 5 Mar 2015 08:15:34 -0500 (EST) 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 t25DFXk0008568; Thu, 5 Mar 2015 08:15:33 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t25DFVoE002289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 08:15:32 -0500 Message-ID: <54F856EC.7070804@mit.edu> Date: Thu, 05 Mar 2015 08:15:24 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , Mike Jones References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F8164E.6040201@gmx.net> <54F84AC8.50109@mit.edu> <54F851B6.9040302@gmx.net> In-Reply-To: <54F851B6.9040302@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hTV1v0W9iPE4OJRVoulO++xWuyd9onF 4uTbV2wOzB6LN+1n81iy5CeTR+uOv+wBzFFcNimpOZllqUX6dglcGfdOL2ctmLqIsaLxw0nG BsZrDYxdjJwcEgImEvdfNLFC2GISF+6tZ+ti5OIQEljMJDHh/29mCGcDo8TXB+/YIZxbTBK9 EzazgbTwCqhJvPzyEGwUi4CqxO3598FGsQHZ09e0MIHYogJREj1/uqHqBSVOznzCAmKLCKRI HJ52AqyeWUBdovf3SjBbWCBAYsW2k6wQy14ySXxf9gesgROo6PXa78wQDWYSXVu7GCFseYnm rbOZJzAKzkKyYxaSsllIyhYwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdfLzSzRS00p3cQI Cm52F5UdjM2HlA4xCnAwKvHwztj4PUSINbGsuDL3EKMkB5OSKG+w8Y8QIb6k/JTKjMTijPii 0pzU4kOMEhzMSiK8e0OBcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxK Ery+II2CRanpqRVpmTklCGkmDk6Q4TxAw5eBDS8uSMwtzkyHyJ9iVJQS500Gpg8hAZBERmke XC8s+bxiFAd6RZj3PUg7DzBxwXW/AhrMBDRYSwxscEkiQkqqgVGkuSDbTzZBMrvP+8XxRSlR J5WOsqp+ehsiY8VnpWR9uI1906EV23tbCg7cm8/+tC0/f9e5bdrbjx58EmbZxXFfzXHmpxXn Uw81lZV+WR++bhrL2/ymqUYGIa6SOp8Ulqy9v2DnuRvNpksDWuMvJyrz+wX8mr1sM+uFiVuF xe0qVsfpvE+zWKnEUpyRaKjFXFScCADaWZH8GQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:15:45 -0000 Hannes, You're on the right track: the "active" claim *is* effectively a top level toggle, much like an error message would be. However, we're taking the same approach that token revocation uses and returning an HTTP OK response with the information inside instead of an HTTP error. This was decided (in both cases) because the HTTP request itself is not in error, nor is there any error state on the server, it's returning information about the object requested. It's actually up to the RS to determine what to do with that in its response back to the client. Furthermore, in many cases, the RS *can't* know and *shouldn't* know how or why the AS makes that determination, just like the client *can't* and *shouldn't* know how the AS generates a token value itself. The client just knows that one was created, or not, in response to an authorization request. Likewise, the RS in this case just knows that the token was good, or not, in response to an introspection request. This type of black-box interoperability is exactly what standards are about and is not hand-wavy at all. In fact, it's telling you exactly what it says on the tin without needlessly disclosing details (leading to a potential oracle attack from an RS fishing for tokens). It's the simplest thing that could possibly work, and it's been shown to work and interoperate between vendors for years in production. If you're building an RS and you're outsourcing AS functionality entirely, then you need to trust that the AS is going to give you the right answer when you ask the question "is this token any good?", which is what's going on here. You as the developer might or might not care how the AS came to that conclusion, but, importantly, it doesn't matter for the protocol how that decision was reached. We can provide guidance for AS developers as in the text that I suggested earlier in this thread, but prescribing behavior beyond that isn't helpful. If you think the definition itself can be more clearly articulated, please propose updated text for us to include. -- Justin On 3/5/2015 7:53 AM, Hannes Tschofenig wrote: > Hi Justin, > > in a security specification we should be able to say exactly what the > semantic of a certain attribute is. > > What I expect happening today is that many organizations provide both > resource server and authorization server and agree in an out-of-band > fashion what the meaning of that value is. This is why we don't hear > back from implementers at this point in time. > > This is, however, not the purpose of standardization. We want to develop > a spec that allows two different vendors to plug their stuff together > and it works without having to agree (out of band) what the semantic if > the different fields is. > > We have already seen in OAuth that vague text does not increase security. > > If the purpose of the active claim is only to say that the AS did some > checks without further indicating what it actually did then we could as > well use the fact that there has been a response to the request (rather > than an error message) as well. That seems to be roughly the level of > semantic we are at with this at the moment. > > I hope you understand that I have to push back on these hand-wavy ideas > since otherwise we need profiles in other organizations that explain > what the IETF OAuth documents really mean. > > Ciao > Hannes > > On 03/05/2015 01:23 PM, Justin Richer wrote: >> The "active" claim boils down to the AS saying "Do I think this token is >> any good or not?" and it's really up to the AS how it determines that. >> Our own implementation does a data store lookup on the token value. If >> it finds the token, then the token is active. If the token had been >> revoked, or expired, then it wouldn't have come out of the data store in >> the first place, and it's not active. I've seen others do the same thing. >> >> Other stateless implementations are going to probably parse the token >> itself and do things like check claims and signatures to see if the >> token's any good. Or they might decrypt the token at the AS (assuming in >> this example that it was encrypted using the AS's key) and dig inside >> the protected structure that's not available to the RS. Once it's inside >> that structure the AS can figure out if the token's active or not, and >> tell the RS. >> >> Or there might be a combination of the two where the AS parses the token >> and checks its signature and then uses some key field in the token to >> look up more information in a data store. If all that checks out then >> the token is active, probably. >> >> And the AS might want to do other checks, like see if this particular RS >> is even allowed to ask about this particular token. >> >> It is not, however, just a sanity check across other claims already >> embedded in the token -- you could very easily use an unstructured >> token. In fact, that's the world that this was first deployed in back >> 4-5 years ago. >> >> The important thing is that as far as the RS is concerned, the AS did >> *some* check on the token and came back with a thumbs up / thumbs down >> response. The thumbs up response can contain other information as well, >> such as scopes and client IDs and whatnot, which can help the RS make >> its authorization decision. But at its core, the "active" claim >> fundamentally says "is this token any good at all, according to the AS >> that I asked?" and the RS can make its primary authorization decision >> based on that. If the RS has made the decision to outsource the token >> validity check to the AS, then the RS either understands or doesn't care >> what checks the AS makes in its decision regardless of implementation or >> vendor. Either way, it will abide by them since that's the whole point >> of outsourcing that decision. >> >> >> And I think you're too quick to dismiss the lack of confusion on the >> part of developers, considering that they are in fact the target >> audience of specifications like this. If we're not writing these >> documents for developers, who are we writing them for? >> >> -- Justin >> >> On 3/5/2015 3:39 AM, Hannes Tschofenig wrote: >>> Hi Mike, Hi Justin, >>> >>> I guess you agree with me that fundamentally the JWT and the token >>> introspection solve the same problem, namely to provide the >>> authorization server with information that it can use to make an >>> authorization decision. The difference is only in the way how the >>> message flows. >>> >>> Now, to the argument that developers have not yet complained about the >>> underspecified claims/attributes is not particularly good. We tend to >>> hear about complains years later when things go wrong and then we cannot >>> change them anymore. >>> >>> Tell me for the active claim what type of checks the authorization >>> server is supposed to do. >>> >>> If the authorization server and the resource server are provided by >>> different parties then it is important to be clear about what checks >>> each of the two parties are supposed to be doing. If the active claim >>> aims to outsource the authorization decision from the resource server to >>> the authorization server then that's a completely different story than >>> just doing some basic sanity check on some of the JWT claims. >>> >>> Ciao >>> Hannes >>> >>> >>> On 03/05/2015 08:36 AM, Mike Jones wrote: >>>> It sounds to me like you're making a good argument for this spec to have >>>> its own registry. Registries are easy to establish and use. >>>> ------------------------------------------------------------------------ >>>> From: Justin Richer >>>> Sent: ‎3/‎4/‎2015 6:43 PM >>>> To: Mike Jones ; Hannes Tschofenig >>>> >>>> Cc: >>>> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection >>>> "Claims" >>>> >>>> I'm actually fine with keeping the introspection-specific elements out >>>> of the registry (see my note on "active" and how it doesn't fit in JWT >>>> below), but I do not want to give up the short names. The short names >>>> are already in production, especially "active", which is well understood >>>> and used in practice today, and has been for years[1]. Changing this >>>> would fundamentally break all existing implementations for no good >>>> reason. I'm slightly more OK with changing "user_id" to "username", >>>> since that's not as widely deployed to my knowledge (other implementers, >>>> please pipe up if I'm mistaken), and I'm well familiar with >>>> "preffered_username" in OIDC because I'm the one that put it in there >>>> [2]. :) While I prefer to leave it be at this stage, I think this is a >>>> less destructive change than "active", "scope", or "client_id" would be. >>>> >>>> For background to my stance regarding the registry: several revisions >>>> (and years) ago, the introspection draft re-defined several fields that >>>> overlapped with JWT and we were asked to correlate the two. Originally, >>>> we simply had a pointer to re-use the JWT claims as defined, and stacked >>>> our own claims on top. Later, we were asked to outright merge them, >>>> which is what we have right now. If the WG wants to back off that last >>>> change to the middle state -- where we re-use the JWT registry but don't >>>> write to it -- I'm very happy with that result and can work that (back) >>>> into the next draft. >>>> >>>> Though it does point out something strange about the standards process >>>> that we're running into here: JWT needed a place to register bits of >>>> metadata about a token, so it created one. This became the "JWT >>>> registry", and now it's got hangings of being "JWT-specific". When >>>> introspection came along with a need to talk about much the same kind of >>>> information, it makes sense to re-use the existing items but also that >>>> there would be things that are introspection-specific. >>>> >>>> -- Justin >>>> >>>> [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 >>>> [2] >>>> https://bitbucket.org/openid/connect/issue/584/messages-username-claim >>>> >>>> On 3/4/2015 6:28 PM, Mike Jones wrote: >>>>> I have severe concerns with this approach. It’s not appropriate to >>>>> register arbitrary JSON object member names as JWT claim names – >>>>> especially when the JSON object member names are not even being used >>>>> as JWT claim names. *Please do not do this*, as it would needlessly >>>>> pollute the JWT claim name namespace with registered names that are >>>>> application specific. >>>>> >>>>> >>>>> Secondarily, I have concerns about these names and suggestions for how >>>>> to address them. >>>>> >>>>> >>>>> “active” – This claim is not presently adequately defined. And its >>>>> definition will of necessity be specific to the introspection >>>>> application. Therefore, it should not be registered as a general JWT >>>>> claim name. A name I would be comfortable with for this concept would >>>>> be urn:ietf:params:oauth:introspection:active, since it makes it clear >>>>> what application the name is used with. >>>>> >>>>> >>>>> “user_id” – The concept you’re describing is almost universally called >>>>> “username”. User ID is typically the numeric account identifier >>>>> (carried in the “sub” claim in a JWT), and so is not the right name >>>>> for this. Compare it to the preferred_username claim in OpenID >>>>> Connect. Please change this either to “username” or >>>>> urn:ietf:params:oauth:introspection:username. >>>>> >>>>> >>>>> “token_type” – While this is well-defined, the usage is fairly >>>>> specific to this application. Again, adding the >>>>> urn:ietf:params:oauth:introspection: name prefix would address this >>>>> issue. >>>>> >>>>> >>>>> If you give up registering these names in the JWT Claims registry, I’m >>>>> OK with you using short names. But if you want them to live alongside >>>>> other JWT claim names, please include the >>>>> urn:ietf:params:oauth:introspection: in lieu of registration. >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin >>>>> Richer >>>>> *Sent:* Wednesday, March 04, 2015 1:46 PM >>>>> *To:* Hannes Tschofenig >>>>> *Cc:* >>>>> *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token >>>>> Introspection "Claims" >>>>> >>>>> >>>>> Hi Hannes, thanks for the feedback. Responses inline. >>>>> >>>>> >>>>> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hi Justin, Hi all, >>>>> >>>>> in OAuth we provide two ways for a resource server to make an >>>>> authorization decision. >>>>> >>>>> 1) The resource server receives a self-contained token that >>>>> contains all >>>>> the necessary information to make a local authorization >>>>> decision. With >>>>> the JWT we have created such a standardized information and data >>>>> model. >>>>> >>>>> 2) With an access request from a client the resource server >>>>> asks the >>>>> authorization server for "help". The authorization server provides >>>>> information that help make the authorization decision. This is the >>>>> token >>>>> introspection approach. >>>>> >>>>> I believe the two approaches need to be aligned with regard to the >>>>> information and the data model. Since both documents already use >>>>> JSON as >>>>> a way to encode information (=data model) and almost have an >>>>> identical >>>>> information model (the data that is being passed around). >>>>> >>>>> What needs to be done? >>>>> >>>>> * Use the term 'claims' in both documents. >>>>> * Use the same registry (i.e., the registry established with >>>>> the JWT). >>>>> * Register the newly defined claims from the token introspection >>>>> document in the claims registry. >>>>> >>>>> >>>>> We’ve already done this in the latest draft. Or at least, that’s the >>>>> intent of the current text — the registry is referenced and the new >>>>> claims are registered. Can you specifically point to places where this >>>>> needs to be improved upon? >>>>> >>>>> >>>>> >>>>> Then, I have a few comments on the new claims that are proposed: >>>>> >>>>> Here is the definition of the 'active' claim: >>>>> >>>>> active >>>>> REQUIRED. Boolean indicator of whether or not the presented >>>>> token >>>>> is currently active. The authorization server determines whether >>>>> and when a given token is in an active state. >>>>> >>>>> This claim is not well-defined. You need to explain what "active" >>>>> means. >>>>> It could, for example, mean that the token is not yet expired. Then, >>>>> there is of course the question why you are not returning the 'exp' >>>>> claim together with the 'nbf' claim. >>>>> >>>>> >>>>> The definition of “active” is really up to the authorization server, >>>>> and I’ve yet to hear from an actual implementor who’s confused by this >>>>> definition. When you’re the one issuing the tokens, you know what an >>>>> “active” token means to you. Still, perhaps we can be even more >>>>> explicit, such as: >>>>> >>>>> >>>>> >>>>> active >>>>> >>>>> REQUIRED. Boolean indicator of whether or not the presented >>>>> token is currently active. The specifics of a token’s active state >>>>> will vary depending on the implementation of the authorization >>>>> server, but generally this will indicate that a given token has >>>>> been issued by this authorization server, has not been revoked by >>>>> the resource owner, and is within its given time window of >>>>> validity (e.g. not expired). >>>>> >>>>> >>>>> Also, this is one of the places where the overlap between JWT and >>>>> introspection claims don’t make sense. It doesn’t make any sense for a >>>>> JWT to carry an “active” claim at all. Why would you have a JWT claim >>>>> to be anything but active? We should register it with the JWT registry >>>>> to avoid name collisions, but there’s nothing in the JWT registry that >>>>> says “don’t use this inside of a JWT”. Do you have any advice on how >>>>> to address this? >>>>> >>>>> >>>>> >>>>> >>>>> client_id: What is the resource server going to do with the client_id? >>>>> What authorization decision could it make? >>>>> >>>>> >>>>> Whatever it wants to. If an RS can figure out something from the >>>>> client_id, why not let it? The client_id is a piece of information >>>>> about the context of the issuance of the token, and a common enough >>>>> OAuth value for decision making. >>>>> >>>>> >>>>> >>>>> I have a couple of reactions when I read the 'user_id' claim: >>>>> - I believe the inclusion of a user id field in the response could >>>>> lead to further confusion regarding OAuth access token usage for >>>>> authentication. >>>>> >>>>> >>>>> This isn’t any different from having a userinfo-endpoint equivalent >>>>> (like social graph or twitter API) and it’s got the same trouble. >>>>> >>>>> >>>>> >>>>> >>>>> - Since you define it as a human readable identifier I am wondering >>>>> whether you want to say something about the usage. Here it seems >>>>> that it >>>>> might be used for displaying something on a webpage rather than making >>>>> an authorization decision but I might well be wrong. >>>>> >>>>> >>>>> We added in “user_id” to our implementation due to developer demand — >>>>> they wanted a username associated with the return value, but to leave >>>>> the “sub” value the same as that defined by OpenID Connect. Note that >>>>> this is in an environment where the username is a known quantity, and >>>>> they’re not trying to do cross-domain authentication. They just want >>>>> to know whose token this was so they can figure out whose data to >>>>> return. It’s not used for display, but I tried to make the definition >>>>> in contrast to the machine-facing “sub” value. >>>>> >>>>> >>>>> >>>>> >>>>> - I am missing a discussion about the privacy implications of it. >>>>> While there is a privacy consideration section I am wondering what >>>>> controls the release of this sensitive information from the >>>>> authorization server to the resource server. While in some cases the >>>>> two >>>>> parties might belong to the same organization but in other cases that >>>>> may not necessarily be true. >>>>> >>>>> >>>>> You’re correct, this is currently missing and I’ll add that in. >>>>> >>>>> >>>>> >>>>> >>>>> - In terms of the information exchanged about the user I am curious >>>>> about the usefulness of including other information as well, such as >>>>> the >>>>> info that is included in an id token (see >>>>> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this >>>>> has nothing to do with the ID token concept and the information carried >>>>> within it then I would add that remark. >>>>> >>>>> >>>>> >>>>> You could introspect an ID token if you wanted to, but it’s usually >>>>> easier to just parse it yourself because it’s self-contained. The ID >>>>> Token also extends JWT, so there’s nothing stopping you from returning >>>>> those claims as well. However, note that the audience of the ID token >>>>> is the OAuth *client* whereas the targeted user of the introspection >>>>> endpoint is the *protected resource*. The PR isn’t going to see the ID >>>>> Token most of the time, and the client’s not going to need to (or be >>>>> able to) introspect its tokens most of the time, so in practice >>>>> there’s not really any overlap. >>>>> >>>>> >>>>> — Justin >>>>> >>>>> >>>>> >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> From nobody Thu Mar 5 06:09:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD81A01A9 for ; Thu, 5 Mar 2015 06:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 73lGMsKSgV-O for ; Thu, 5 Mar 2015 06:08:58 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 2BA1D1B2CE8 for ; Thu, 5 Mar 2015 06:04:05 -0800 (PST) Received: by wibbs8 with SMTP id bs8so7231367wib.4 for ; Thu, 05 Mar 2015 06:04:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WR05QDB5Dn7nQHClqKYobYFHRqFUaz+8cClLEEM9hxU=; b=D3gkfyxbRHDpVDnPK6QT5uSorFRPTw1VWTwDEeOZGBDY1E7UnKolfWBtBn9ithMHZS 2gszTK920NQvhaOYa7CrtghJLOnlGMWqD2jmWr1ePTSHhr11hVDKggApslvwFujncfwo zJAtZc7Oe0udmJoGgHRm8J5zBPdw//6Buo1sUCHYntnZ7P9Ux+emSi3ZZIy2AroN4YB5 ESNTE79aaB+nMIFkuE+68Ev8Dn2cPZ8P5W2KTDgsAxg3z3eDYtB3JG7gxVr0vbie15qK zqNvfXLOChe3l7FDXGN/hYZHLYmeSkYeNjaFqKyM9AFr+92BHFMCDxPoMiKVcTm35W4m aJrg== X-Gm-Message-State: ALoCoQkmPZu6cP948lCp0MKS+bZf4mFZiUXzRBuJ0HNpjJaKBRJn8hbTUabwjAajyLa1ySJSk7oc X-Received: by 10.194.8.2 with SMTP id n2mr18772476wja.46.1425564243683; Thu, 05 Mar 2015 06:04:03 -0800 (PST) Received: from [192.168.43.33] ([95.131.169.235]) by mx.google.com with ESMTPSA id uo6sm10651934wjc.49.2015.03.05.06.04.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 06:04:02 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-14016EBB-66CD-4165-8782-5D087DEF576C Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (12B466) In-Reply-To: <54F853E2.9030405@mit.edu> Date: Thu, 5 Mar 2015 15:04:00 +0100 Content-Transfer-Encoding: 7bit Message-Id: <743ED77C-2536-4C95-A69A-4C1D6CA31F5E@ve7jtb.com> References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F84B3D.1090401@mit.edu> <9B6A57FD-4D82-4475-B2BE-6EC87D235754@ve7jtb.com> <54F853E2.9030405@mit.edu> To: Justin Richer Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:09:03 -0000 --Apple-Mail-14016EBB-66CD-4165-8782-5D087DEF576C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Others will hate the idea as well for other reasons I expect.=20 If we leave introspection aside it might be a way to deal with other specs g= oing forward.=20 Sent from my iPhone > On Mar 5, 2015, at 2:02 PM, Justin Richer wrote: >=20 > And you're right that I *really* don't like this because it breaks existin= g implementations somewhat arbitrarily. Mike had suggested something similar= . >=20 > -- Justin >=20 >> On 3/5/2015 7:48 AM, John Bradley wrote: >> A middle ground, that perhaps no one will like is registering applicatio= n specific claims in the JWT registry, but pretending them with a app names= pace.=20 >>=20 >> Eg >> Int:active >>=20 >> That prevents people from stepping on each other with short names, and g= ives a central place to look them up, without requiring all all alls to und= erstand all claims.=20 >>=20 >> John B.=20 >>=20 >> Sent from my iPhone >>=20 >> On Mar 5, 2015, at 1:25 PM, Justin Richer wrote: >>=20 >>> I'm OK with a separate registry, my only question is whether or not ther= e's a way to correlate and coordinate the values of the two registries. The c= oncern with importing the JWT claims directly into introspection's response w= as that we'd potentially be stepping on an existing namespace. In practice, I= don't think that's a concern, but I can see the argument. If we establish a= n introspection response registry, how do we continue to deconflict with the= JWT registry? >>>=20 >>> -- Justin >>>=20 >>>> On 3/5/2015 2:36 AM, Mike Jones wrote: >>>> It sounds to me like you're making a good argument for this spec to hav= e its own registry. Registries are easy to establish and use. >>>> From: Justin Richer >>>> Sent: =E2=80=8E3/=E2=80=8E4/=E2=80=8E2015 6:43 PM >>>> To: Mike Jones; Hannes Tschofenig >>>> Cc: >>>> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection= "Claims" >>>>=20 >>>> I'm actually fine with keeping the introspection-specific elements out o= f the registry (see my note on "active" and how it doesn't fit in JWT below)= , but I do not want to give up the short names. The short names are already i= n production, especially "active", which is well understood and used in prac= tice today, and has been for years[1]. Changing this would fundamentally bre= ak all existing implementations for no good reason. I'm slightly more OK wit= h changing "user_id" to "username", since that's not as widely deployed to m= y knowledge (other implementers, please pipe up if I'm mistaken), and I'm we= ll familiar with "preffered_username" in OIDC because I'm the one that put i= t in there [2]. :) While I prefer to leave it be at this stage, I think this= is a less destructive change than "active", "scope", or "client_id" would b= e.=20 >>>>=20 >>>> For background to my stance regarding the registry: several revisions (= and years) ago, the introspection draft re-defined several fields that overl= apped with JWT and we were asked to correlate the two. Originally, we simply= had a pointer to re-use the JWT claims as defined, and stacked our own clai= ms on top. Later, we were asked to outright merge them, which is what we hav= e right now. If the WG wants to back off that last change to the middle stat= e -- where we re-use the JWT registry but don't write to it -- I'm very happ= y with that result and can work that (back) into the next draft. >>>>=20 >>>> Though it does point out something strange about the standards process t= hat we're running into here: JWT needed a place to register bits of metadata= about a token, so it created one. This became the "JWT registry", and now i= t's got hangings of being "JWT-specific". When introspection came along with= a need to talk about much the same kind of information, it makes sense to r= e-use the existing items but also that there would be things that are intros= pection-specific.=20 >>>>=20 >>>> -- Justin >>>>=20 >>>> [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 >>>> [2] https://bitbucket.org/openid/connect/issue/584/messages-username-cl= aim >>>>=20 >>>>> On 3/4/2015 6:28 PM, Mike Jones wrote: >>>>> I have severe concerns with this approach. It=E2=80=99s not appropria= te to register arbitrary JSON object member names as JWT claim names =E2=80=93= especially when the JSON object member names are not even being used as JWT= claim names. Please do not do this, as it would needlessly pollute the JWT= claim name namespace with registered names that are application = specific. >>>>> =20 >>>>> Secondarily, I have concerns about these names and suggestions for how= to address them. >>>>> =20 >>>>> =E2=80=9Cactive=E2=80=9D =E2=80=93 This claim is not presently adequat= ely defined. And its definition will of necessity be specific to the intros= pection application. Therefore, it should not be registered as a general JW= T claim name. A name I would be comfortable with for this concept would be u= rn:ietf:params:oauth:introspection:active, since it makes it clear what appl= ication the name is used with. >>>>> =20 >>>>> =E2=80=9Cuser_id=E2=80=9D =E2=80=93 The concept you=E2=80=99re describ= ing is almost universally called =E2=80=9Cusername=E2=80=9D. User ID is typ= ically the numeric account identifier (carried in the =E2=80=9Csub=E2=80=9D c= laim in a JWT), and so is not the right name for this. Compare it to the pr= eferred_username claim in OpenID Connect. Please change this either to =E2=80= =9Cusername=E2=80=9D or urn:ietf:params:oauth:introspection:username. >>>>> =20 >>>>> =E2=80=9Ctoken_type=E2=80=9D =E2=80=93 While this is well-defined, the= usage is fairly specific to this application. Again, adding the urn:ietf:p= arams:oauth:introspection: name prefix would address this issue. >>>>> =20 >>>>> If you give up registering these names in the JWT Claims registry, I=E2= =80=99m OK with you using short names. But if you want them to live alongsi= de other JWT claim names, please include the urn:ietf:params:oauth:introspec= tion: in lieu of registration. >>>>> =20 >>>>> Thank you,= >>>>> -- Mike >>>>> =20 >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer= >>>>> Sent: Wednesday, March 04, 2015 1:46 PM >>>>> To: Hannes Tschofenig >>>>> Cc: >>>>> Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspectio= n "Claims" >>>>> =20 >>>>> Hi Hannes, thanks for the feedback. Responses inline. >>>>> =20 >>>>> On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig wrote: >>>>> =20 >>>>> Hi Justin, Hi all, >>>>>=20 >>>>> in OAuth we provide two ways for a resource server to make an >>>>> authorization decision. >>>>>=20 >>>>> 1) The resource server receives a self-contained token that contains a= ll >>>>> the necessary information to make a local authorization decision. With= >>>>> the JWT we have created such a standardized information and data model= . >>>>>=20 >>>>> 2) With an access request from a client the = resource server asks the >>>>> authorization server for "help". The authorization server provides >>>>> information that help make the authorization decision. This is the tok= en >>>>> introspection approach. >>>>>=20 >>>>> I believe the two approaches need to be aligned with regard to the >>>>> information and the data model. Since both documents already use JSON a= s >>>>> a way to encode information (=3Ddata model) and almost have an identic= al >>>>> information model (the data that is being passed around). >>>>>=20 >>>>> What needs to be done? >>>>>=20 >>>>> * Use the term 'claims' in both documents. >>>>> * Use the same registry (i.e., the registry established with the JWT).= >>>>> * Register the newly defined claims from the token introspection >>>>> document in the claims registry. >>>>>=20 >>>>> =20 >>>>> We=E2=80=99ve already done this in the latest draft. Or at least, that= =E2=80=99s the intent of the current text =E2=80=94 the registry is referenc= ed and the new claims are registered. Can you specifically point to places w= here this needs to be improved upon? >>>>>=20 >>>>>=20 >>>>> Then, I have a few comments on the new claims that are proposed: >>>>>=20 >>>>> Here is the definition of the 'active' claim: >>>>>=20 >>>>> active >>>>> REQUIRED. Boolean indicator of whether or not the presented toke= n >>>>> is currently active. The authorization server determines whether= >>>>> and when a given token is in an active state. >>>>>=20 >>>>> This claim is not well-defined. You need to explain what "active" mean= s. >>>>> It could, for example, mean that the token is = not yet expired. Then, >>>>> there is of course the question why you are not returning the 'exp' >>>>> claim together with the 'nbf' claim. >>>>> =20 >>>>> The definition of =E2=80=9Cactive=E2=80=9D is really up to the authori= zation server, and I=E2=80=99ve yet to hear from an actual implementor who=E2= =80=99s confused by this definition. When you=E2=80=99re the one issuing the= tokens, you know what an =E2=80=9Cactive=E2=80=9D token means to you. Still= , perhaps we can be even more explicit, such as: >>>>> =20 >>>>> =20 >>>>> active >>>>> REQUIRED. Boolean indicator of whether or not the presented token is= currently active. The specifics of a token=E2=80=99s = active state will vary depending on the implementation of the authorizatio= n server, but generally this will indicate that a given token has been issue= d by this authorization server, has not been revoked by the resource owner, a= nd is within its given time window of validity (e.g. not expired).=20 >>>>> =20 >>>>> Also, this is one of the places where the overlap between JWT and intr= ospection claims don=E2=80=99t make sense. It doesn=E2=80=99t make any sense= for a JWT to carry an =E2=80=9Cactive=E2=80=9D claim at all. Why would you h= ave a JWT claim to be anything but active? We should register it with the JW= T registry to avoid name collisions, but there=E2=80=99s nothing in the JWT r= egistry that says =E2=80=9Cdon=E2=80=99t use this inside = of a JWT=E2=80=9D. Do you have any advice on how to address this? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> client_id: What is the resource server going = to do with the client_id? >>>>> What authorization decision could it make? >>>>> =20 >>>>> Whatever it wants to. If an RS can figure out something from the clien= t_id, why not let it? The client_id is a piece of information about the cont= ext of the issuance of the token, and a common enough OAuth value for decisi= on making.=20 >>>>>=20 >>>>>=20 >>>>> I have a couple of reactions when I read the 'user_id' claim: >>>>> - I believe the inclusion of a user id field in the response could >>>>> lead to further confusion regarding OAuth access token usage for >>>>> authentication. >>>>> =20 >>>>> This isn=E2=80=99t any different from having a userinfo-endpoint equiv= alent (like social graph or twitter API) and it=E2=80=99s got the same troub= le.=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> - Since you define it as a human readable identifier I am wondering >>>>> whether you want to say something about the usage. Here it seems that i= t >>>>> might be used for displaying something on a webpage rather than making= >>>>> an authorization decision but I might well be wrong. >>>>> =20 >>>>> We added in =E2=80=9Cuser_id=E2=80=9D to our implementation due to dev= eloper demand =E2=80=94 they wanted a username associated with the return va= lue, but to leave the =E2=80=9Csub=E2=80=9D value the same as that defined b= y OpenID Connect. Note that this is in an environment where the username is a= known quantity, and they=E2=80=99re not trying to do cross-domain authentic= ation. They just want to know whose token this was so they can figure out wh= ose data to return. It=E2=80=99s not used for display, but I tried to make t= he definition in contrast to the machine-facing =E2=80=9Csub=E2=80=9D value.= >>>>>=20 >>>>>=20 >>>>>=20 >>>>> - I am missing a discussion about the privacy implications of it. >>>>> While there is a privacy consideration section I am wondering what >>>>> controls the release of this sensitive information from the >>>>> authorization server to the resource server. While in some cases the t= wo >>>>> parties might belong to the same organization but in other cases that >>>>> may not necessarily be true. >>>>> =20 >>>>> You=E2=80=99re correct, this is currently missing and I=E2=80=99ll add= that in. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> - In terms of the information exchanged about the user I am curious >>>>> about the usefulness of including other information as well, such as t= he >>>>> info that is included in an id token (see >>>>> http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this= >>>>> has nothing to do with the ID token concept a= nd the information carried >>>>> within it then I would add that remark. >>>>> =20 >>>>> =20 >>>>> You could introspect an ID token if you wanted to, but it=E2=80=99s us= ually easier to just parse it yourself because it=E2=80=99s self-contained. T= he ID Token also extends JWT, so there=E2=80=99s nothing stopping you from r= eturning those claims as well. However, note that the audience of the ID tok= en is the OAuth *client* whereas the targeted user of the introspection endp= oint is the *protected resource*. The PR isn=E2=80=99t going to see the ID T= oken most of the time, and the client=E2=80=99s not going to need to (or be a= ble to) introspect its tokens most of the time, so in practice there=E2=80=99= s not really any overlap. >>>>> =20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=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 --Apple-Mail-14016EBB-66CD-4165-8782-5D087DEF576C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Others will hate the idea as well for o= ther reasons I expect. 

If we leave introspect= ion aside it might be a way to deal with other specs going forward. 
Sent from my iPhone

On Mar 5, 2015, at 2:02 PM, Justin Ri= cher <jricher@mit.edu> wrote:
=20 =20 =20 And you're right that I *really* don't like this because it breaks existing implementations somewhat arbitrarily. Mike had suggested something similar.

 -- Justin

On 3/5/2015 7:48 AM, John Bradley wrote:
A middle ground,  that perhaps no one will like is registering application specific claims in the JWT registry,  but pretending them with a app namespace. 

Eg
Int:active

That prevents people from stepping on each other with short names,  and gives a central place to look them up,  withou= t requiring all all alls to understand all claims. 

John B. 

Sent from my iPhone

On Mar 5, 2015, at 1:25 PM, Justin Richer <jricher@mit.edu> wrote:

I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry?

 -- Justin

On 3/5/2015 2:36 AM, Mike Jones wrote:
It sounds to me like you're making a good argument for this spec to have its own registry.  Registries are easy to establish and use.
From: Justin Richer
Sent: =E2=80=8E3/=E2=80=8E4/=E2=80= =8E2015 6:43 PM
To: Mike Jones; Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on "active" and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially "active", which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing "user_id" to "username", since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with "preffered_username" in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than "active", "scope", or "client_id" would be.

For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft.

Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the "JWT registry", and now it's got hangings of being "JWT-specific". When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific.

 -- Justin

[1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03
[2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim=

On 3/4/2015 6:28 PM, Mike Jones wrote:

I have severe concerns with this approach.  It=E2=80=99s not appropriate to regist= er arbitrary JSON object member names as JWT claim names =E2=80=93 especially when the JSON object member= names are not even being used as JWT claim names. = ; Please do not do this, as it would needlessly pollute the JWT claim name namespace with registered names that are application specific.

 

Secondarily, I have concerns about these names and suggestions for how to address them.

 

=E2=80=9Cactive=E2=80=9D =E2=80=93 This= claim is not presently adequately defined.  And its definition= will of necessity be specific to the introspection application.  Therefore, it should not be registered as a general JWT claim name.  A name I= would be comfortable with for this concept would be urn:ietf:params:oauth:introspection:active, since it makes it clear what application the name is used with.

 

=E2=80=9Cuser_id=E2=80=9D =E2=80=93 The= concept you=E2=80=99re describing is almost universally called =E2=80=9Cusername=E2=80=9D.  User ID is typically= the numeric account identifier (carried in the =E2=80=9Csub=E2=80=9D= claim in a JWT), and so is not the right name for this.  Compare it to the preferred_username claim in OpenID Connect.  Please change this either to =E2=80=9Cusername=E2=80=9D or urn:ietf:params:oauth:introspection:username.

 

=E2=80=9Ctoken_type=E2=80=9D =E2=80=93 W= hile this is well-defined, the usage is fairly specific to this application.  Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue.

 

If you give up registering these names in the JWT Claims registry, I=E2=80=99m OK with y= ou using short names.  But if you want them to live alongside other JWT claim names, please include the urn:ietf:params:oauth:introspection: in lieu of registration.

 

      &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;  Thank you,

      &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;  -- Mike

 

From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, March 04, 2015 1:46 PM
= To: Hannes Tschofenig
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"=

 

Hi Hannes, thanks for the feedback. Responses inline.

 

 

Hi Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=3Ddata model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

* Use the term 'claims' in both documents.
* Use the same registry (i.e., the registry established with the JWT).
* Register the newly defined claims from the token introspection
document in the claims registry.

 

We=E2=80=99ve already done th= is in the latest draft. Or at least, that=E2=80=99s the intent of the current text =E2=80=94 the registry i= s referenced and the new claims are registered. Can you specifically point to places where this needs to be improved upon?



Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

  active
     REQUIRED.  Bool= ean indicator of whether or not the presented token
     is currently active.=  The authorization server determines whether
     and when a given tok= en is in an active state.

This claim is not well-defined. You need to explain what "active" means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

 

The definition of =E2=80=9Cac= tive=E2=80=9D is really up to the authorization server, and I=E2=80=99ve yet to hear from an actual implemento= r who=E2=80=99s confused by this definition. When yo= u=E2=80=99re the one issuing the tokens, you know what an =E2=80=9Cactive=E2=80=9D token means to you. Still= , perhaps we can be even more explicit, such as:

 

 

active

  REQUIRED. Boolean indica= tor of whether or not the presented token is currently active. The specifics of a token=E2=80=99s= active state will vary depending on the implementation of the authorization server, but generally this will indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g. not expired). 

 

Also, this is one of the places where the overlap between JWT and introspection claims don=E2=80=99t make sense. It doesn=E2=80=99t make any sense for a JWT to carry a= n =E2=80=9Cactive=E2=80=9D claim at all. Why would y= ou have a JWT claim to be anything but active? We should register it with the JWT registry to avoid name collisions, but there=E2=80=99s nothing in th= e JWT registry that says =E2=80=9Cdon=E2=80=99t use t= his inside of a JWT=E2=80=9D. Do you have any advice on how t= o address this?




client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

 

Whatever it wants to. If an RS can figure out something from the client_id, why not let it? The client_id is a piece of information about the context of the issuance of the token, and a common enough OAuth value for decision making. 



I have a couple of reactions when I read the 'user_id' claim:
 - I believe the inclusion of a user id field= in the response could
lead to further confusion regarding OAuth access token usage for
authentication.

 

This isn=E2=80=99t any differ= ent from having a userinfo-endpoint equivalent (like social graph or twitter API) and it=E2=80=99= s got the same trouble. 




 - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

 

We added in =E2=80=9Cuser_id=E2= =80=9D to our implementation due to developer demand =E2=80=94= they wanted a username associated with the return value, but to leave the =E2=80=9Csub=E2=80=9D= value the same as that defined by OpenID Connect. Note that this is in an environment where the username is a known quantity, and they=E2=80=99re n= ot trying to do cross-domain authentication. They just want to know whose token this was so they can figure out whose data to return. It=E2=80=99s n= ot used for display, but I tried to make the definition in contrast to the machine-facing =E2=80=9Csub=E2=80=9D value.




 - I am missing a discussion about the privac= y implications of it.
While there is a privacy consideration section I am wondering what
controls the release of this sensitive information from the
authorization server to the resource server. While in some cases the two
parties might belong to the same organization but in other cases that
may not necessarily be true.

 

You=E2=80=99re correct, this i= s currently missing and I=E2=80=99ll add that in.



 

 

You could introspect an ID token if you wanted to, but it=E2=80=99s usually easier to just parse it yourself because it=E2=80=99= s self-contained. The ID Token also extends JWT, so there=E2=80=99s nothing stopping you from retur= ning those claims as well. However, note that the audience of the ID token is the OAuth *client* whereas the targeted user of the introspection endpoint is the *protected resource*. The PR isn=E2=80=99t going to see the ID Token most of th= e time, and the client=E2=80=99s not going to need t= o (or be able to) introspect its tokens most of the time, so in practice there=E2=80=99s not reall= y any overlap.

 

 =E2=80=94 Justin




Ciao
Hannes

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

 




=20
= --Apple-Mail-14016EBB-66CD-4165-8782-5D087DEF576C-- From nobody Thu Mar 5 06:16:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C2E1A0372 for ; Thu, 5 Mar 2015 06:15:58 -0800 (PST) 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 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 1iWzuvaJimuy for ; Thu, 5 Mar 2015 06:15:54 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 25AB71A0389 for ; Thu, 5 Mar 2015 06:10:42 -0800 (PST) Received: by wivr20 with SMTP id r20so7082947wiv.5 for ; Thu, 05 Mar 2015 06:10:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=54qyKBehPOiqFMRmou+xHAMAjkF+CM9egMWCq9+d9Ck=; b=Oc9AFLWmRy6ejsrOgD+cI1ew+BFIoylG/Xd/vTo4RYXIZZOJi7moXt5sKrrBBUv0df rmCV6byAQjrtNibVZzf7oH/h/F0W/I7PA7hMEHIgotzwIMpThQUnqusw/ek8aZT7QVEl OHpNnvqqTtZtNai2zwI7OyIILN1E92ESoykk5vfZZRF4pJxH/t5BRb5L/AiZk2Gp/7BY QSPG5TPGSon8xyl9aKVsPkvuxk59+zKlmGpjRXwRdzMyA6e8ZSIK2B2b7rRjKFlfXaQU RgIrCD7WEzdtrJ63ID7kZzuILEKo/T5Vy4lQx6lQaaEJR4Z+LuqcQVkmbqmWuPKV0J47 ok3w== X-Gm-Message-State: ALoCoQkrDqrML9w21aYDurFq/nW/hcpffuIYOgtcHtURqujBb4PajXU0lpz2yyCCof93CRCh6yyt X-Received: by 10.194.122.196 with SMTP id lu4mr18953145wjb.154.1425564640943; Thu, 05 Mar 2015 06:10:40 -0800 (PST) Received: from [192.168.43.33] ([95.131.169.235]) by mx.google.com with ESMTPSA id hl8sm10681339wjb.38.2015.03.05.06.10.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 06:10:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (12B466) In-Reply-To: <54F8545B.4010602@gmx.net> Date: Thu, 5 Mar 2015 15:10:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47BD998C-69F1-41EE-8CD6-BBDE8ABC0150@ve7jtb.com> References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net> <54F84F69.2090408@gmx.net> <54F8545B.4010602@gmx.net> To: Hannes Tschofenig Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:15:58 -0000 Clients that share a common client_id can't pre register. You need to be d= oing per instance dynamic client registration for that to work.=20 Non confidential clients need to push a key with code, or have it provisione= d by the AS with the AT.=20 Sent from my iPhone > On Mar 5, 2015, at 2:04 PM, Hannes Tschofenig w= rote: >=20 > Actually, I am not sure my statement below is actually correct. >=20 > We need to distinguish the case where the client id is unique per client > software instance and when it isn't. >=20 > If the client id is shared by multiple client software instances then > how do we make sure that clients aren't uploading keys that either have > no kid or have an kid that is not unique (since they don't know about > the existence of other client instances or that other client instances > have already uploaded a jwk with the same kid). >=20 > Any idea how to address that problem? >=20 > Ciao > Hannes >=20 >> On 03/05/2015 01:43 PM, Hannes Tschofenig wrote: >> Hi John, >>=20 >> that's a good idea. However, the dynamic client registration should >> state that the "kid" parameter is used and must be included in the JWK >> (since the kid is an optional parameter). >>=20 >> The key name is then the 'kid' plus the client id since the value of the >> kid is not unique by itself. >>=20 >> Ciao >> Hannes >>=20 >>> On 03/05/2015 12:54 PM, John Bradley wrote: >>> For signing authentication requests you include the keyid in the JWT, an= d the AS looks in the JWKS to find the correct key if there is more than one= . >>>=20 >>> I don't think that is a problem >>>=20 >>> What we probably need to do is pass a keyid in the request if there is m= ore than one signing key registered for the client. >>>=20 >>> John B. >=20 From nobody Thu Mar 5 10:11:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFDC1A6EF0 for ; Thu, 5 Mar 2015 10:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 JGQak-54BiA7 for ; Thu, 5 Mar 2015 10:11:06 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23531A6ED9 for ; Thu, 5 Mar 2015 10:11:05 -0800 (PST) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (25.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.99.14; Thu, 5 Mar 2015 18:11:03 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0099.004; Thu, 5 Mar 2015 18:11:03 +0000 From: Anthony Nadalin To: Mike Jones , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline Thread-Index: AQHQVolBYKU2iEv0rEGFakA1XyRiFJ0M93/wgAACxYCAATVkgA== Date: Thu, 5 Mar 2015 18:11:03 +0000 Message-ID: References: <54F71978.5090804@gmx.net> <4E1F6AAD24975D4BA5B1680429673943A2E78DFF@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E78DFF@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: microsoft.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(53754006)(13464003)(76576001)(106116001)(87936001)(74316001)(99286002)(2656002)(230783001)(2561002)(102836002)(107886001)(15975445007)(2950100001)(46102003)(62966003)(77156002)(2501003)(1511001)(86362001)(19580395003)(122556002)(54356999)(92566002)(33656002)(76176999)(2900100001)(561944003)(19580405001)(40100003)(50986999)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 05066DEDBB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2015 18:11:03.3359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 18:11:09 -0000 This can't be limited to JWE Compact Serialization, we have keys that use t= he JSON binary serialization. "cnf" seems underspecified, as this could be a JWK (but not it's not a MUST= ), and thus I may understand "cnf" but only when used with a JWK and not so= me other invented structure. So how do I tell what "cnf" really is ? Is this proposal also limited to a single key for both asymmetric and symm= etric ? -----Original Message----- From: Mike Jones=20 Sent: Wednesday, March 4, 2015 3:34 PM To: Anthony Nadalin; Hannes Tschofenig; oauth@ietf.org Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Op= en Issues before the Deadline It does so for the same reason that the JWT spec does - to promote interope= rability. We can add wording along the likes of "the JWE Compact Serializa= tion MUST be used" if you like. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Wednesday, March 04, 2015 3:26 PM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Op= en Issues before the Deadline Why does the specification state "encrypted to a key known to the recipient= using the JWE Compact Serialization" is this the only serialization allowe= d (there is no MUST) ? containing the symmetric key. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, March 4, 2015 6:41 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open I= ssues before the Deadline Hi all, as the deadline is approaching I would like to close the open issues of the= document. There are two open issues listed in the document and I propose w= ays to resolve them below Open Issue #1: "In some conversations, we have said that it is the issuer of the JWT that possesses the key, and in some conversations, we have said that it is the presenter of the JWT that possesses the key. Which description should we use? " There are the following parties in the entire picture (as the PoP architect= ure document illustrates quite nicely): * Issuer: Party that creates the JWT and binds a key to the token. The key may be a symmetric key or a public key. To bind the key to the JWT = the issuer needs to compute a digital signature or a keyed message digest o= ver the JWT. * Presenter: Party that demonstrates possession of a private key (for asymm= etric key cryptography) and secret key (for symmetric key cryptography) to a recipient. * Recipient: Party that receives the JWT together with the proof of possess= ion of the key (typically in form of a digital signature or a keyed message= digest). Mapping this terminology to the OAuth context would look as follows: - Issuer: OAuth Authorization Server - Presenter: OAuth Client - Recipient: OAuth Resource Server Adding the above-mentioned terminology to the terminology section (and dele= ting the currently listed presenter) would resolve the issue IMHO. Open Issue#2: Mike added an editorial note to the introduction saying: " [[ Editorial Note: This paragraph needs to be updated to provide more context and possibly also to describe the use of asymmetric keys instead. It's not clear that the symmetric case is as useful or valuable, and it is certainly more complicated.]] " The design team work clearly indicated that both symmetric and asymmetric c= ryptography has to be supported. The JWT mechanism actually supports both a= nd hence we should also describe both. What can, however, be done is to als= o describe the asymmetric key case and here is my text proposal for the int= roduction. ---- 1. Introduction This specification defines how to bind a key to a JSON Web Token (JWT) [JWT]. Three parties act in such a scenario: * Issuer: Party that creates the JWT and binds a key to the token. The key may be a symmetric key or a public key. To bind the key to the JWT = the issuer needs to compute a digital signature or a keyed message digest o= ver the JWT. * Presenter: Party that demonstrates possession of a private key (for asymm= etric key cryptography) and secret key (for symmetric key cryptography) to = a recipient. This property is also sometimes described as the presenter bei= ng a holder-of-key. * Recipient: Party that receives the JWT together with the proof of possess= ion of the key (typically in form of a digital signature or a keyed message= digest). [I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession = semantics for JSON Web Tokens (JWTs) for the use with OAuth. Envision the following two use cases. The first use case describes the use of a symmetric key and the second use case focuses on asymmetric cryptography. An OAuth 2.0 authorization server generates a JWT and places an encrypted symmetric key inside the newly introduced confirmation claim. This symmetric key is encrypted with a key known only to the authorization server and the recipient. The entire JWT is then integrity protected. The JWT is then sent to the presenter. Since the presenter is unable to obtain the encrypted symmetric key from the JWT itself, the authorization server conveys that symmetric key separately to the presenter. Now, the presenter is in possession of the symmetric key as well as the JWT (which includes the confirmation claim member). When the presenter needs to present the JWT to the recipient, it also needs to demonstrate possession of the symmetric key; the presenter, for example, uses the symmetric key in a challenge/response protocol with the recipient. The recipient is able to verify that it is interacting with the genuine presenter by decrypting the JWK contained inside the confirmation claim of the JWT. By doing this the recipient obtains the symmetric key, which it then uses to verify cryptographically protected messages exchanged with the presenter. This symmetric key mechanism described above is conceptually similar to the use of Kerberos tickets. In the second case consider a presenter that generates a public / private key pair. It then sends the public key to an OAuth 2.0 authorization server, which creates a JWT and places an public key (or a fingerprint of it) inside the newly introduced confirmation claim. The entire JWT is then integrity protected using a digital signature to protect it against modifications. The JWT is then sent to the presenter. When the presenter needs to present the JWT to the recipient, it also needs to demonstrate possession of the private key. The presenter, for example, uses the private key in TLS exchange with the recipient. The recipient is able to verify that it is interacting with the genuine presenter by extracting the public key from the confirmation claim of the JWT (after verifying the digital signature of the JWT) and utilizing it with the private key in the TLS exchange. The asymmetric key mechanism described above is conceptually similar to a certificate. In both cases the JWT may contain various claims that are included based on the policy of the authorization server. ---- Due to the IETF draft submission deadline we would appreciate a response by= next Sunday. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Mar 5 10:48:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7BF1A701A for ; Thu, 5 Mar 2015 10:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 CyrbSfK9czu0 for ; Thu, 5 Mar 2015 10:48:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76701A7021 for ; Thu, 5 Mar 2015 10:48:32 -0800 (PST) Received: from DM2PR03CA0023.namprd03.prod.outlook.com (10.141.96.22) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.1.99.9; Thu, 5 Mar 2015 18:48:30 +0000 Received: from BN1BFFO11FD053.protection.gbl (2a01:111:f400:7c10::1:199) by DM2PR03CA0023.outlook.office365.com (2a01:111:e400:2428::22) with Microsoft SMTP Server (TLS) id 15.1.99.14 via Frontend Transport; Thu, 5 Mar 2015 18:48:30 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD053.mail.protection.outlook.com (10.58.145.8) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Thu, 5 Mar 2015 18:48:30 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.74]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0224.003; Thu, 5 Mar 2015 18:47:52 +0000 From: Mike Jones To: Anthony Nadalin , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline Thread-Index: AQHQVolBIxzQq7Nzg0mQ91i99DI7Cp0M+AcAgAABVsCAATkLgIAACDbA Date: Thu, 5 Mar 2015 18:47:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E7AE92@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <54F71978.5090804@gmx.net> <4E1F6AAD24975D4BA5B1680429673943A2E78DFF@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; gmx.net; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(53754006)(13464003)(199003)(377454003)(106466001)(2950100001)(2920100001)(2900100001)(50466002)(106116001)(561944003)(23726002)(92566002)(107886001)(33656002)(50986999)(46102003)(76176999)(62966003)(102836002)(15975445007)(54356999)(77156002)(46406003)(2501003)(93886004)(230783001)(97756001)(1511001)(66066001)(87936001)(55846006)(47776003)(2561002)(6806004)(19580405001)(19580395003)(104016003)(86362001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB079; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB079; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001007); SRVR:SN2PR03MB079; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB079; X-Forefront-PRVS: 05066DEDBB X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2015 18:48:30.5343 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB079 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 18:48:37 -0000 Per https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-01#sec= tion-3.1, keys can be represented as JWKs (which are JSON objects), so I th= ink the draft already does what you're asking for in that regard. If that'= s not what you're asking for, maybe we can talk about it in person and dete= rmine what actions to propose. The "cnf" syntax is based on existing practice as already in production use= by XBOX One and its partners. That in turn was loosely based on the SAML = SubjectConfirmation element - existing semantic practice that we tried to f= ollow for JWTs. Sure, applications can specify ways of sending lots of keys, including proo= f-of-possession keys, and different keys for different purposes. They'd pr= obably define claims with application-specific meanings to do that, which i= s fine. This spec is trying to cover the common case, where a single subje= ct conformation key is used for a particular security token. Having the co= mmon case covered doesn't take away the ability to do more complicated appl= ication-specific things, if needed. -- Mike -----Original Message----- From: Anthony Nadalin=20 Sent: Thursday, March 05, 2015 10:11 AM To: Mike Jones; Hannes Tschofenig; oauth@ietf.org Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Op= en Issues before the Deadline This can't be limited to JWE Compact Serialization, we have keys that use t= he JSON binary serialization. "cnf" seems underspecified, as this could be a JWK (but not it's not a MUST= ), and thus I may understand "cnf" but only when used with a JWK and not so= me other invented structure. So how do I tell what "cnf" really is ? Is this proposal also limited to a single key for both asymmetric and symm= etric ? -----Original Message----- From: Mike Jones=20 Sent: Wednesday, March 4, 2015 3:34 PM To: Anthony Nadalin; Hannes Tschofenig; oauth@ietf.org Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Op= en Issues before the Deadline It does so for the same reason that the JWT spec does - to promote interope= rability. We can add wording along the likes of "the JWE Compact Serializa= tion MUST be used" if you like. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Wednesday, March 04, 2015 3:26 PM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Op= en Issues before the Deadline Why does the specification state "encrypted to a key known to the recipient= using the JWE Compact Serialization" is this the only serialization allowe= d (there is no MUST) ? containing the symmetric key. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, March 4, 2015 6:41 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open I= ssues before the Deadline Hi all, as the deadline is approaching I would like to close the open issues of the= document. There are two open issues listed in the document and I propose w= ays to resolve them below Open Issue #1: "In some conversations, we have said that it is the issuer of the JWT that possesses the key, and in some conversations, we have said that it is the presenter of the JWT that possesses the key. Which description should we use? " There are the following parties in the entire picture (as the PoP architect= ure document illustrates quite nicely): * Issuer: Party that creates the JWT and binds a key to the token. The key may be a symmetric key or a public key. To bind the key to the JWT = the issuer needs to compute a digital signature or a keyed message digest o= ver the JWT. * Presenter: Party that demonstrates possession of a private key (for asymm= etric key cryptography) and secret key (for symmetric key cryptography) to a recipient. * Recipient: Party that receives the JWT together with the proof of possess= ion of the key (typically in form of a digital signature or a keyed message= digest). Mapping this terminology to the OAuth context would look as follows: - Issuer: OAuth Authorization Server - Presenter: OAuth Client - Recipient: OAuth Resource Server Adding the above-mentioned terminology to the terminology section (and dele= ting the currently listed presenter) would resolve the issue IMHO. Open Issue#2: Mike added an editorial note to the introduction saying: " [[ Editorial Note: This paragraph needs to be updated to provide more context and possibly also to describe the use of asymmetric keys instead. It's not clear that the symmetric case is as useful or valuable, and it is certainly more complicated.]] " The design team work clearly indicated that both symmetric and asymmetric c= ryptography has to be supported. The JWT mechanism actually supports both a= nd hence we should also describe both. What can, however, be done is to als= o describe the asymmetric key case and here is my text proposal for the int= roduction. ---- 1. Introduction This specification defines how to bind a key to a JSON Web Token (JWT) [JWT]. Three parties act in such a scenario: * Issuer: Party that creates the JWT and binds a key to the token. The key may be a symmetric key or a public key. To bind the key to the JWT = the issuer needs to compute a digital signature or a keyed message digest o= ver the JWT. * Presenter: Party that demonstrates possession of a private key (for asymm= etric key cryptography) and secret key (for symmetric key cryptography) to = a recipient. This property is also sometimes described as the presenter bei= ng a holder-of-key. * Recipient: Party that receives the JWT together with the proof of possess= ion of the key (typically in form of a digital signature or a keyed message= digest). [I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession = semantics for JSON Web Tokens (JWTs) for the use with OAuth. Envision the following two use cases. The first use case describes the use of a symmetric key and the second use case focuses on asymmetric cryptography. An OAuth 2.0 authorization server generates a JWT and places an encrypted symmetric key inside the newly introduced confirmation claim. This symmetric key is encrypted with a key known only to the authorization server and the recipient. The entire JWT is then integrity protected. The JWT is then sent to the presenter. Since the presenter is unable to obtain the encrypted symmetric key from the JWT itself, the authorization server conveys that symmetric key separately to the presenter. Now, the presenter is in possession of the symmetric key as well as the JWT (which includes the confirmation claim member). When the presenter needs to present the JWT to the recipient, it also needs to demonstrate possession of the symmetric key; the presenter, for example, uses the symmetric key in a challenge/response protocol with the recipient. The recipient is able to verify that it is interacting with the genuine presenter by decrypting the JWK contained inside the confirmation claim of the JWT. By doing this the recipient obtains the symmetric key, which it then uses to verify cryptographically protected messages exchanged with the presenter. This symmetric key mechanism described above is conceptually similar to the use of Kerberos tickets. In the second case consider a presenter that generates a public / private key pair. It then sends the public key to an OAuth 2.0 authorization server, which creates a JWT and places an public key (or a fingerprint of it) inside the newly introduced confirmation claim. The entire JWT is then integrity protected using a digital signature to protect it against modifications. The JWT is then sent to the presenter. When the presenter needs to present the JWT to the recipient, it also needs to demonstrate possession of the private key. The presenter, for example, uses the private key in TLS exchange with the recipient. The recipient is able to verify that it is interacting with the genuine presenter by extracting the public key from the confirmation claim of the JWT (after verifying the digital signature of the JWT) and utilizing it with the private key in the TLS exchange. The asymmetric key mechanism described above is conceptually similar to a certificate. In both cases the JWT may contain various claims that are included based on the policy of the authorization server. ---- Due to the IETF draft submission deadline we would appreciate a response by= next Sunday. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Mar 5 13:21:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472641A8979 for ; Thu, 5 Mar 2015 13:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Z3sg4ibqzjsz for ; Thu, 5 Mar 2015 13:21:00 -0800 (PST) Received: from nm41-vm9.bullet.mail.bf1.yahoo.com (nm41-vm9.bullet.mail.bf1.yahoo.com [216.109.114.138]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CE81A6F02 for ; Thu, 5 Mar 2015 13:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1425590459; bh=vyVxL0nmEPST95l48eL5hLPPT9ycT05Bi9wisXJ56p8=; h=Date:From:Reply-To:To:Cc:Subject:From:Subject; b=EZCMX2qnOMmO+Ic4SY+mqKZ/g9z497yS6HGuydCXKNrbQ24VTCNgG3vW3xEAuKG/WZE+5/kTBcfW6riz0P+lh9QlOVP0QQAKXACcFju/RNMIol33Xv0/GEwJ47vshiwW6cS1wBDegQ8/fJnHww3AKIt4oWviJLDBpkZ6m6ldoIyGsczXX2cOm05/Yh+T4qiYOFXvwU6WlDhhnbjAR2jS5AhnsuIrqOKmx86YAA7/70mlF3I+Z7Bw3bzGCPbNorWM9DdqfRGvRPpuFFQDaCw7d3QPA/r88qDc0u+Q7GlmEuUaXB6yeMVUXxcc2DFVYVFbhilVeONF8gwBievuBo0hIg== Received: from [98.139.215.140] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 05 Mar 2015 21:20:59 -0000 Received: from [98.139.212.242] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 05 Mar 2015 21:20:59 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 05 Mar 2015 21:20:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 563349.68550.bm@omp1051.mail.bf1.yahoo.com X-YMail-OSG: lTjfreQVM1lKlHr.CYXXnSo4zL5Guj46gffdLkNQ2moLQXTlduhJOXfl_Y4AIbo o6Pcq5bIIMQJ4NgqdOtf9voEwzUSik.0o_uggoDZq0INlxJW4klMzoNr3q1Qe5d5pn_TKinAHMRM EahS6WyR6h33.B8QnSuYLjZHX5nAFZLcGx6PXByMAPQY4y17fh4oq8qyEQ6qCuiiundVXQqR4.6s qE0rV5A5356MGs7iCxm92ps8HZJFRe1WZIOWbYTbc_RqrHizNHnNNSOy.fSTjrU1OWunNbYvjjII BRg63U_zb89BUfYIrI3ldu1p8SK6rxrUUhd5JCVAqMGiCux.3EZqPkCD948sDwfzUtJUV898DaTZ _8oLbB6WjPGo0TbFLLLxLx8zaZ0eKrdt0uDfpJFtyu3nCbfFTlZEwkZ0hFU66IBJdVT3RFVKJVmd 9j6Zu2Wb2KTpNbx0t9D6mbkxmICth5rK9_9PG8iUgU_ThuWZziShb4_7_uWAdTwJpaVCcYc_zrC2 GGST4BSy3hLFWZTZfkRd_bN4hwJ2UYmzEDNW7dpZCcoYwpwEn2Es2FQZMYs1HgDbNwexSFcQody6 W.1HVff9GkF3EkWnpdIvnRIW6Zx67av_.x3LpLPr7crvrDz3SN9dmvxFZCA-- Received: by 66.196.81.108; Thu, 05 Mar 2015 21:20:58 +0000 Date: Thu, 5 Mar 2015 21:20:58 +0000 (UTC) From: Bill Mills To: Hannes Tschofenig Message-ID: <512094072.5360931.1425590458090.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5360930_119453657.1425590458089" Archived-At: Cc: OAuth WG Subject: [OAUTH-WG] http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 21:21:01 -0000 ------=_Part_5360930_119453657.1425590458089 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hannes, Please update my e-mail to wimills@microsoft.com and my affilliation to Microsoft in the next draft. Thanks, -bill ------=_Part_5360930_119453657.1425590458089 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hannes,

Please update my e-mail to wimills@microsoft.com and my affilliation to Microsoft in the next draft.

Thanks,

-bill
------=_Part_5360930_119453657.1425590458089-- From nobody Thu Mar 5 15:11:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988E21A9073 for ; Thu, 5 Mar 2015 15:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 shhcFM7EoVql for ; Thu, 5 Mar 2015 15:11:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0757.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::757]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB77A1A8979 for ; Thu, 5 Mar 2015 15:11:12 -0800 (PST) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.99.14; Thu, 5 Mar 2015 23:10:53 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0099.004; Thu, 5 Mar 2015 23:10:53 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: Token Introspection: Misc Review Comments Thread-Index: AdBXcRALxHf+M7itSuKMynHPiKrpaQ== Date: Thu, 5 Mar 2015 23:10:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: gmx.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(50986999)(46102003)(40100003)(54356999)(107886001)(92566002)(2656002)(87936001)(122556002)(77156002)(102836002)(62966003)(99286002)(229853001)(86612001)(2501003)(76576001)(86362001)(33656002)(74316001)(2900100001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 05066DEDBB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2015 23:10:53.5029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Subject: [OAUTH-WG] Token Introspection: Misc Review Comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 23:11:14 -0000 U29tZSBjb21tZW50czoNCg0KPiBUaGUgZW5kcG9pbnQgTUFZIGFsbG93IG90aGVyIHBhcmFtZXRl cnMgdG8gcHJvdmlkZSBmdXJ0aGVyIGNvbnRleHQgdG8gdGhlIHF1ZXJ5Lg0KDQpJZiB0aGUgZW5k cG9pbnQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGVzZSB0aGUgZW5kcG9pbnQgbXVzdCBpZ25vcmUu DQoNClRoZSBvbmx5IE1VU1QgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIGlzIHRvIHJldHVybiB0aGUg ImFjdGl2ZSIgQm9vbGVhbiwgYnV0IHRoaXMgaXMgc3RpbGwgdW5kZXJzcGVjaWZpZWQgYXMgdGhl cmUgaXMgbm8gZGVmaW5pdGlvbiBvciBjcml0ZXJpYSB0aGF0IGEgZGV2ZWxvcGVyIGhhcyB0byBn byB1cG9uIHRvIGRldGVybWluZSBpZiB0aGF0IEJvb2xlYW4gaXMgc2V0IG9yIG5vdC4NCg0KdG9r ZW5fdHlwZV9oaW50ICBpcyByZWFsbHkgbm90IGEgdHlwZSBoaW50IGJ1dCBqdXN0IGEgdG9rZW4g aGludCBhbmQgdGh1cyBzaG91bGQgYmUgY2huYWdlZA0KDQo= From nobody Fri Mar 6 09:22:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AFA1A00DC for ; Fri, 6 Mar 2015 09:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ah0mvwyl4QZB for ; Fri, 6 Mar 2015 09:22:30 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 D17FE1A0072 for ; Fri, 6 Mar 2015 09:22:29 -0800 (PST) Received: by wibbs8 with SMTP id bs8so5195642wib.0 for ; Fri, 06 Mar 2015 09:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=IaxjTR/hWOSWsAlPKK1Jr2DgN5EZbYiklceJ+AQhGCc=; b=sZAfwSECzbp9AoZ8nWWw+KrqqhkHqzrQE1zmskFxsYEObVAfws9JICsYBY30pwchqa FVJL2a9gBsSbGHQQ7AJ9jS4upubDHAW6jBtpA1Jv+DqSdRwvoEJWB2iVv8zZXuiDaoM/ 80isQrYk0ZctZVz5IcYBXb77qzJ2x3eUxY0V9g8OjjVo694R8cSV35mGS2/IUIXAdNqi /jKankh474jIVT49gN2I/DAiYiCx+bmSKejCTHumHBEeN5QUDlbUTGgQSHOjej3GBshp AwpjQo8rpnQmgG3SudG7D+oAcIZpR3VsKMlmsAAPCAYEzCj8WjBNhq6kvehRbAGtiBe+ 6p0w== X-Received: by 10.180.77.19 with SMTP id o19mr13908549wiw.90.1425662548713; Fri, 06 Mar 2015 09:22:28 -0800 (PST) Received: from [192.168.2.7] ([89.100.10.58]) by mx.google.com with ESMTPSA id e18sm15800441wjz.27.2015.03.06.09.22.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 09:22:27 -0800 (PST) Message-ID: <54F9E246.70901@gmail.com> Date: Fri, 06 Mar 2015 17:22:14 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: oauth@ietf.org References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Returning tokens directly to a human user X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 17:22:34 -0000 Hi All, We might have a requirement to support a case where AS returns an access token directly to a human user, with the user subsequently configuring a confidential client with this token. The actual client is not capable of supporting a (more dynamic) code flow at this stage. So it is nearly like an implicit code flow except that the user is asked upfront which clients can get the tokens allocated and the token is returned in the HTML response without redirecting and placing the token in a fragment. Apparently a number of big providers do just that, let users allocate tokens for some clients with the users expected to copy the tokens into the confidential clients afterwards. I'd like to ask, it is a reasonable approach, to have tokens transferred manually into the confidential client ? Would it be more appropriate for a user to request a code and then copy it to the confidential client and expect it to get the tokens itself. I guess the problem here may be a code is short lived, but so is a typical access token - but the latter can be supported by a refresh one. Another question: does it even qualify as an OAuth2 grant for token exchange, the process of a user pre-authorizing a client and getting not a code but tokens back ? I guess it does, so how a grant like this one would typically be called ? We'd have no problems with assigning some custom name to such a grant but curious how others approach it... Thanks, Sergey From nobody Fri Mar 6 10:00:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95081A0021 for ; Fri, 6 Mar 2015 10:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Yy6vEfG8SUeB for ; Fri, 6 Mar 2015 09:59:59 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c: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 1F9AE1A00DC for ; Fri, 6 Mar 2015 09:59:59 -0800 (PST) Received: by wghl2 with SMTP id l2so17873306wgh.8 for ; Fri, 06 Mar 2015 09:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7RBUgidvtgUVk3QqxCfX4JyxNDQpPa+l+4zOgdTIr3U=; b=GA32kbeY5zO83u2jpd3ibImpiqnkuBluMoaV4NsZZTc18sUlTiVN1Fp1O5blhQu69K iR3ju7kq8PBgTkHcPmRUqe3c3kaxNgzrGI43HrG0jkR86UvoQ8NtkjNScYp6+lvQ3/cZ WQRYPOvdSCpkMQ15pOJgMwBSeNYCYeM9x22vKKOorYZiX8A4N18nRNWbkzj7aOlAylGP 5r3n23ENjFiOTtyLocEJKWVxO3ioQRm68dwesaeHpSaHnxIPXw2pKtdpnAdJMoS2TSsk yA+uk/oTFXEBFvQjzcIBmc8iNPIEH2RFE7pJIhOyFqcQus+myoNLRi6IwAz5TuV2R4i8 xtew== X-Received: by 10.194.189.138 with SMTP id gi10mr32636422wjc.86.1425664797966; Fri, 06 Mar 2015 09:59:57 -0800 (PST) Received: from [192.168.2.7] ([89.100.10.58]) by mx.google.com with ESMTPSA id ew5sm3211442wic.14.2015.03.06.09.59.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 09:59:56 -0800 (PST) Message-ID: <54F9EB19.3010706@gmail.com> Date: Fri, 06 Mar 2015 17:59:53 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: oauth@ietf.org References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F9E246.70901@gmail.com> In-Reply-To: <54F9E246.70901@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Using refresh tokens to authenticate the clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:00:00 -0000 Hi All, The example at [1] suggests that clients working with a refresh grant authenticate as usual when they need to use a grant. The section 3.3 in the threat model document [2] says that "as long as the confidentiality of the particular token can be ensured by the client, a refresh token can also be used as an alternative means to authenticate the client instance itself" How this can be processed by the access token service that expects a client to authenticate ? Example, typically, Authorization: Basic encodedInfo If a refresh token is used to authenticate, how to express it ? client_id=refreshToken in the form payload or URI query ? Thanks, Sergey [1] https://tools.ietf.org/html/rfc6749#section-6 [2] https://tools.ietf.org/html/rfc6819#section-3.3 From nobody Fri Mar 6 10:07:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42D11A1AB8 for ; Fri, 6 Mar 2015 10:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 j7PXEFC_S10C for ; Fri, 6 Mar 2015 10:07:53 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 C8A641A1A97 for ; Fri, 6 Mar 2015 10:07:52 -0800 (PST) Received: by qgea108 with SMTP id a108so14497279qge.8 for ; Fri, 06 Mar 2015 10:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KD6XYbOVFRAjCIGwbcpdEUBeDDApo7OzdB3bhgxHW6o=; b=iyUTnARsmSgfkZtL75MkLH90BNpK1K1OH4NVhXTSq0xtKmW98fVLE3Yr/wKaoLI8LM 4hqaQbmEx/jkCxPh4KdRlVCAHulX09ls8KptkPPpz9lRV6pBWr1lP/XVVdEr2ZQyFbVi lmnG/qo3WoXoJcmyxFFju161ZUutaIDZpXgfIOlkkcxWkPVeM/ssvKxkk+dhpjjDz1jk yunvWlextA29X1oLZwhrlzB2/p5uaGAgi5aQekiBLKX0pwFI1VugYWFVrcZFrTtPWhy8 y52ciaJP+h/YvkNvst6KTo/7u+rv3Zg/9BDsdFFDxu3kyRv6m8d/CTgtjrh6TsrbDYF0 uhCA== X-Received: by 10.55.41.69 with SMTP id p66mr31151254qkh.101.1425665271817; Fri, 06 Mar 2015 10:07:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.84 with HTTP; Fri, 6 Mar 2015 10:07:31 -0800 (PST) In-Reply-To: <54F9E246.70901@gmail.com> References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F9E246.70901@gmail.com> From: Dick Hardt Date: Fri, 6 Mar 2015 10:07:31 -0800 Message-ID: To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=001a1147af32186c290510a290af Archived-At: Cc: Oauth Wrap Wg Subject: Re: [OAUTH-WG] Returning tokens directly to a human user X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:07:54 -0000 --001a1147af32186c290510a290af Content-Type: text/plain; charset=UTF-8 If you are interested in how others have done a similar flow, you could look at how smart TVs supporting Netflix and Amazon are authorized. On Fri, Mar 6, 2015 at 9:22 AM, Sergey Beryozkin wrote: > Hi All, > > We might have a requirement to support a case where AS returns an access > token directly to a human user, with the user subsequently configuring a > confidential client with this token. The actual client is not capable of > supporting a (more dynamic) code flow at this stage. > > So it is nearly like an implicit code flow except that the user is asked > upfront which clients can get the tokens allocated and the token is > returned in the HTML response without redirecting and placing the token in > a fragment. > > Apparently a number of big providers do just that, let users allocate > tokens for some clients with the users expected to copy the tokens into the > confidential clients afterwards. > > I'd like to ask, it is a reasonable approach, to have tokens transferred > manually into the confidential client ? > > Would it be more appropriate for a user to request a code and then copy it > to the confidential client and expect it to get the tokens itself. I guess > the problem here may be a code is short lived, but so is a typical access > token - but the latter can be supported by a refresh one. > > Another question: does it even qualify as an OAuth2 grant for token > exchange, the process of a user pre-authorizing a client and getting not a > code but tokens back ? I guess it does, so how a grant like this one would > typically be called ? We'd have no problems with assigning some custom name > to such a grant but curious how others approach it... > > Thanks, Sergey > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1147af32186c290510a290af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you are interested in how others have done a similar fl= ow, you could look at how smart TVs supporting Netflix and Amazon are autho= rized.

On Fr= i, Mar 6, 2015 at 9:22 AM, Sergey Beryozkin <sberyozkin@gmail.com= > wrote:
Hi All,

We might have a requirement to support a case where AS returns an access to= ken directly to a human user, with the user subsequently configuring a conf= idential client with this token. The actual client is not capable of suppor= ting a (more dynamic) code flow at this stage.

So it is nearly like an implicit code flow except that the user is asked up= front which clients can get the tokens allocated and the token is returned = in the HTML response without redirecting and placing the token in a fragmen= t.

Apparently a number of big providers do just that, let users allocate token= s for some clients with the users expected to copy the tokens into the conf= idential clients afterwards.

I'd like to ask, it is a reasonable approach, to have tokens transferre= d manually into the confidential client ?

Would it be more appropriate for a user to request a code and then copy it = to the confidential client and expect it to get the tokens itself. I guess = the problem here may be a code is short lived, but so is a typical access t= oken - but the latter can be supported by a refresh one.

Another question: does it even qualify as an OAuth2 grant for token exchang= e, the process of a user pre-authorizing a client and getting not a code bu= t tokens back ? I guess it does, so how a grant like this one would typical= ly be called ? We'd have no problems with assigning some custom name to= such a grant but curious how others approach it...

Thanks, Sergey




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

--001a1147af32186c290510a290af-- From nobody Fri Mar 6 10:29:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D061A1B72 for ; Fri, 6 Mar 2015 10:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8qOs556ZmsjL for ; Fri, 6 Mar 2015 10:28:57 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1C01A1B2D for ; Fri, 6 Mar 2015 10:28:57 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-d6-54f9f1e7fdee 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.72.21729.7E1F9F45; Fri, 6 Mar 2015 13:28:56 -0500 (EST) 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 t26IStPd013481; Fri, 6 Mar 2015 13:28:55 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t26ISrEe008355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Mar 2015 13:28:54 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_63D7876E-AF8D-41DC-A58A-A2AF709B5576"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Justin Richer In-Reply-To: <54F9E246.70901@gmail.com> Date: Fri, 6 Mar 2015 13:28:52 -0500 Message-Id: <52A4984A-5ACE-472D-986D-54012EB620C2@mit.edu> References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <, > <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F9E246.70901@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA01SW0hTYRznO7udTY8d5+1zOUZDk5SZSQ928VL54KOEJfRgnrmvbbRNOWcT Z5JWRmYa1oORNHJeujhhY6Q1hRzDly0CfZDMSlQCayZqF9FQ6RzP1N5+3/93+f//fH9cIPeL FLjRYkW0hTKpxTKhXJqQqfm2ulGa7VwAucGlsDh3u6+gECv2dX6RFPf2bmAl2CXZaR0yGWsQ fTS/QmYYabotqe5X1a65bwgawXZyC8BxSB6H/pC2BUhZmAjHZ9ziFiDD5WQPBj1/u0X8wwPg K3dfhJnF4PDNdxLOEkeegX6vR8hhgsyGjtBvjBMJyIcAvgiEBHyuAs5+GgAcFpNp8NFAE8Zh KZkOZ7Y2d+pCMhX6XVw7nDWnwzvBIj7zJBz50wT4xj4MLrVt7WTGk5lwYnFawq+ggq1efTuI 7fxvjM7/x+AIAWt55lyM4CNw9N5zIY9V8PXSk0j9BOx5PBWp58Hp+10Yj/PhfEe3qAvg/UCp M9dpzJTRxKBKDVNJWSyI1uRmmY3WLKSzeQH3OZKitDegPaAOABIH6miiWbFRKhdRNYzdHADJ OKZOILTLbClGW6WzGyjGcJm2mRATAKlsr3mPaxwohJYqC1LHEw/mWB2ho+x1iK7alR3Eheok wrseUyon9ZQVXUWoGtG7bAqOqyHRsMIaY2mkR7VXjCbrPo3h0gCAeDQbPsVpCKaaMjNGPc+H wCFFEvGLI0iOMNgse97dwwuDJHatOGKOU0WzZ7nnDrPBGBuckbjOBVupfUrRCFTajoKcnLFz g2gl/XB9u/Ju2Wh5cMvqgnkX+s6WwOHr43LxaPBnpbxNAibPO9vWHRXXbMsfX9YvxH5vHdEX fa1PihrabBB0a+bQxDLRc2DN1/x50O0o+6Esv2gPfvCsntp+W9halvb+6eSk81YoyuF2OIYa UnzK8FhClkugFjIG6liGgGaof6Ft8JtTAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Returning tokens directly to a human user X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:29:00 -0000 --Apple-Mail=_63D7876E-AF8D-41DC-A58A-A2AF709B5576 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All you=E2=80=99re really doing here is having a more manual and less = automated portion for part of the process. You=E2=80=99d want to do this = using a registered redirect URI that hosts the HTML page, and then = you=E2=80=99d need a control in the app itself where the user could = interact. I would personally recommend using this approach to move an = authorization code manually instead of moving an access token. Assuming = your client can access the auth server directly (using the backchannel, = no browser), you should be able to POST to the token endpoint and get = the token directly without the user having to handle it. The reason = being that auth codes are client-limited and much more time-limited, and = their leakage doesn=E2=80=99t immediately lead to leakage of API access. We had a similar approach with a limited client back in the OAuth 1.0 = days, where we had an HTML page that would print the oauth_verify code = on the screen that the user would type into the application. These days, = on most platforms, it=E2=80=99s much easier to register a custom URL = handler or use another system service to get the code directly that this = hack has all but disappeared, at least in my view. =E2=80=94 Justin > On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin = wrote: >=20 > Hi All, >=20 > We might have a requirement to support a case where AS returns an = access token directly to a human user, with the user subsequently = configuring a confidential client with this token. The actual client is = not capable of supporting a (more dynamic) code flow at this stage. >=20 > So it is nearly like an implicit code flow except that the user is = asked upfront which clients can get the tokens allocated and the token = is returned in the HTML response without redirecting and placing the = token in a fragment. >=20 > Apparently a number of big providers do just that, let users allocate = tokens for some clients with the users expected to copy the tokens into = the confidential clients afterwards. >=20 > I'd like to ask, it is a reasonable approach, to have tokens = transferred manually into the confidential client ? >=20 > Would it be more appropriate for a user to request a code and then = copy it to the confidential client and expect it to get the tokens = itself. I guess the problem here may be a code is short lived, but so is = a typical access token - but the latter can be supported by a refresh = one. >=20 > Another question: does it even qualify as an OAuth2 grant for token = exchange, the process of a user pre-authorizing a client and getting not = a code but tokens back ? I guess it does, so how a grant like this one = would typically be called ? We'd have no problems with assigning some = custom name to such a grant but curious how others approach it... >=20 > Thanks, Sergey >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_63D7876E-AF8D-41DC-A58A-A2AF709B5576 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJU+fHlAAoJEDPAngkbd+w9SncH/1BrDfqJkM7tP5J6F4E9E4Dy YM461jR7DRTNZjIEY9vSu6kKIyprwr6zhVC3yJg2rQRIV7fsKSVq1lnaQNmEM7Ah bPkDhZ7y4HlZR75KIBm0KFc62qwgVggKY6dmcMtNNsdWOOCZpg+hl4ZqSo378hi8 ysfxOh3tgTiVZn52Jfo35QpdZVNLtfaQp36ety4mdCHGkas0WjhwBNnpZOBekkac Rih4W0SU1jlna8HOVK+v4Tg1e4ZWyEa8D0Es+6HSP+IOYwCZ18/YKm1mbh0npLqF wUlRcpu+fGUacGiuu31BCSRijrCynnslJCjX4iIAaQxnUILuf3GtNfZJDM12rIA= =k2JZ -----END PGP SIGNATURE----- --Apple-Mail=_63D7876E-AF8D-41DC-A58A-A2AF709B5576-- From nobody Fri Mar 6 11:00:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B7C1A1A45 for ; Fri, 6 Mar 2015 11:00:07 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CO7Q7uU5ia0Y for ; Fri, 6 Mar 2015 11:00:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6DF1A1BA7 for ; Fri, 6 Mar 2015 11:00:05 -0800 (PST) Received: from [192.168.131.143] ([80.92.121.102]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LpbJm-1XrrZF2l3m-00fRci for ; Fri, 06 Mar 2015 20:00:03 +0100 Message-ID: <54F9F932.7060701@gmx.net> Date: Fri, 06 Mar 2015 20:00:02 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <54F9CB3D.4000200@cs.tcd.ie> In-Reply-To: <54F9CB3D.4000200@cs.tcd.ie> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <54F9CB3D.4000200@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="94E6rN6kQshtQfu4aUR8mVhhe2Rti4Hvo" X-Provags-ID: V03:K0:Q6Aw0Y4sYHn6npYXw0ev76P7qS8+ZddDWNKn0e0bp8I4tpPomFl tIl/XiKhPMoCbG1Y9Th9Q9ovd13NnDmrVEk69rs8hIgZPDaMGVag+h9AXuI9BvFQGlqir0A ZEE1g2ga6yoAWBb3XmsGsednY+O6INQAHKDc5XDIj53ZXBtspdd6g98dQfNXcpCOPt/KXH+ m8onVL8oLnenu/K0J2W/g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:00:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --94E6rN6kQshtQfu4aUR8mVhhe2Rti4Hvo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, does anyone have free cycles to review draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a way that is similar to the proof-of-possession work with a new access token format. Ciao Hannes -------- Forwarded Message -------- Subject: [saag] tram draft - anyone willing to help out? Date: Fri, 06 Mar 2015 15:43:57 +0000 From: Stephen Farrell To: saag@ietf.org Hiya, There's a draft in IESG eval that attracted a bunch of perhaps fundamental discusses and comments [1] about its security properties. I think this may be one where the authors could do with a bit more help from the security mafia^H^H^H^H^Hcommunity. (I looked at their wg list and only see a v. thin smattering of names I'd recognise from this list.) So if you're willing and have a little time, please let me know and/or get in touch with the authors. And btw - this might not seem so important but I'd worry it may end up being a major source of system level vulnerabilities for WebRTC deployments if we get it wrong and many sites don't deploy usefully good security for this bit of the WebRTC story. Thanks in advance, S. [1] https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b= allot/ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --94E6rN6kQshtQfu4aUR8mVhhe2Rti4Hvo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+fkyAAoJEGhJURNOOiAtKJwH/jGe/53OXLW6bs54UCWDTLhg QsR1KMgYReT0btVX7S77MYdQ+iCRyV0P7dFomIciiIEsJ8RQhEJwVsplyXHby+QK cw2BOUgWaWn7Ev7nkH1itI95gzbW02FKPW89lEyqthixNOOIfo40Zz1JtfXAXOtQ 1b/NknIKilNlLM4cfrndgemxAhIRhqa7XSlv6dHxMLEGQ+BGN7gfsTkFbq8J5Src RshqA/LfzphadMPy2opHgzb+Vad9+cQx5Vc053pyqp3EvfLHM8NGFPK6TtKGrJqP 1+ugd6/BdmCTnToWXnKDuJ51gP/0+IGcAv9YHc4WaK0/rG2b0QgOPjvQOFZPlaU= =RzsC -----END PGP SIGNATURE----- --94E6rN6kQshtQfu4aUR8mVhhe2Rti4Hvo-- From nobody Fri Mar 6 14:20:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F631A0143 for ; Fri, 6 Mar 2015 14:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZwdUdP9TihwW for ; Fri, 6 Mar 2015 14:20:32 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 6D1981A0100 for ; Fri, 6 Mar 2015 14:20:32 -0800 (PST) Received: by wibhm9 with SMTP id hm9so6830826wib.2 for ; Fri, 06 Mar 2015 14:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=M62WLJielXC78rSUAnb+9kJfYMokOhwQrtUHELSXuqw=; b=R37+iWsWrDi8hQnIA6aedt/0Y/0Q7XLzoIExNca8lXmYUehr8fBSncHgmq1gB28oCg 89C7euXo779XpgnwzXsWm7YaSTKxihV0pWFIVZFlzVU3znMdEzk3MSLll8tGEREpfAWC v5HrsbQuxjhT7IhONGblGqjuPYQ2oPQXU9Vym2FJgaFWj4WE7o6jHAetxg1aIHwrJWAp EUPEKKe3uyTNEnUnMvaSxhZQr+Hgj/z422ounQfl/dhp0hudbBuqcYkHmHEB99FUvTwm rerd7VmA7Yt59wPawDpQmkIkf4VSKXdUgPfBGEeurvJkWxiANvMSQADtuTkBkImc5Bx4 OjEA== X-Received: by 10.194.208.229 with SMTP id mh5mr13718002wjc.108.1425680431265; Fri, 06 Mar 2015 14:20:31 -0800 (PST) Received: from [192.168.2.7] ([89.100.10.58]) by mx.google.com with ESMTPSA id hd10sm3368188wib.7.2015.03.06.14.20.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 14:20:30 -0800 (PST) Message-ID: <54FA2829.7090107@gmail.com> Date: Fri, 06 Mar 2015 22:20:25 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dick Hardt References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F9E246.70901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Oauth Wrap Wg Subject: Re: [OAUTH-WG] Returning tokens directly to a human user X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 22:20:38 -0000 Thanks for a reference to such applications... Sergey On 06/03/15 18:07, Dick Hardt wrote: > If you are interested in how others have done a similar flow, you could > look at how smart TVs supporting Netflix and Amazon are authorized. > > On Fri, Mar 6, 2015 at 9:22 AM, Sergey Beryozkin > wrote: > > Hi All, > > We might have a requirement to support a case where AS returns an > access token directly to a human user, with the user subsequently > configuring a confidential client with this token. The actual client > is not capable of supporting a (more dynamic) code flow at this stage. > > So it is nearly like an implicit code flow except that the user is > asked upfront which clients can get the tokens allocated and the > token is returned in the HTML response without redirecting and > placing the token in a fragment. > > Apparently a number of big providers do just that, let users > allocate tokens for some clients with the users expected to copy the > tokens into the confidential clients afterwards. > > I'd like to ask, it is a reasonable approach, to have tokens > transferred manually into the confidential client ? > > Would it be more appropriate for a user to request a code and then > copy it to the confidential client and expect it to get the tokens > itself. I guess the problem here may be a code is short lived, but > so is a typical access token - but the latter can be supported by a > refresh one. > > Another question: does it even qualify as an OAuth2 grant for token > exchange, the process of a user pre-authorizing a client and getting > not a code but tokens back ? I guess it does, so how a grant like > this one would typically be called ? We'd have no problems with > assigning some custom name to such a grant but curious how others > approach it... > > Thanks, Sergey > > > > > _________________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/__listinfo/oauth > > > From nobody Fri Mar 6 14:31:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E011A00A2 for ; Fri, 6 Mar 2015 14:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 eSQbjPyP9OVy for ; Fri, 6 Mar 2015 14:31:55 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 BFD681A1AA1 for ; Fri, 6 Mar 2015 14:31:54 -0800 (PST) Received: by wibhm9 with SMTP id hm9so6935625wib.2 for ; Fri, 06 Mar 2015 14:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PCbGLLWAg6vscG4ev4dKes8roTM1tFkJi+FQ6hSwjHc=; b=aMKk+nh/Z/ze8exbFVjrVaIyppEPfkyj+wr4XgKJqfiW8K4/Rd+XYL6fjsRbz0M9Ks SMsftHBfgICQHCoMtozKx4Zvz6GYKu+5pbOSkUHInnpj7vNdQ9t6Bb1P0JDWFTNJ6t5T 0//s4Anqyxe8RGrM9wcea3smefUZpYnkLikRt8w7Ts8i1KMeTivuaRVzMiH80hxI9d8i GjjrS/9R1mYzdn8ghob4kGvZ0AAGNq7Y0v3zSEIUtygQFvGifHEeJQ3KUCL0pXDAKpmS +v0MS1dkeSxJHQXbcvWKAj2juxhhgjvDeJj+9w3KVZZZsPVnvNGBngD1XfIveUXk6Bg7 g8eg== X-Received: by 10.180.8.10 with SMTP id n10mr36550026wia.79.1425681113592; Fri, 06 Mar 2015 14:31:53 -0800 (PST) Received: from [192.168.2.7] ([89.100.10.58]) by mx.google.com with ESMTPSA id w4sm4108009wib.19.2015.03.06.14.31.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 14:31:52 -0800 (PST) Message-ID: <54FA2AD7.7000500@gmail.com> Date: Fri, 06 Mar 2015 22:31:51 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Richer References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <, > <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F9E246.70901@gmail.com> <52A4984A-5ACE-472D-986D-54012EB620C2@mit.edu> In-Reply-To: <52A4984A-5ACE-472D-986D-54012EB620C2@mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Returning tokens directly to a human user X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 22:31:57 -0000 Hi On 06/03/15 18:28, Justin Richer wrote: > All you’re really doing here is having a more manual and less automated portion for part of the process. You’d want to do this using a registered redirect URI that hosts the HTML page, and then you’d need a control in the app itself where the user could interact. > > I would personally recommend using this approach to move an authorization code manually instead of moving an access token. Assuming your client can access the auth server directly (using the backchannel, no browser), you should be able to POST to the token endpoint and get the token directly without the user having to handle it. The reason being that auth codes are client-limited and much more time-limited, and their leakage doesn’t immediately lead to leakage of API access. > Right now this is what I'm considering, whether to restrict it to the client getting the tokens itself, with the inserted code, or indirectly, after the user does it. We already support the former for public clients, I guess in the latter case a token will also be linked to a client because a user will enter a client id when requesting a token. Just not sure yet if a 3rd party client will be 'prepared' as you say to interact directly with AS, I guess it will be given that it is expected it should be able to refresh... > We had a similar approach with a limited client back in the OAuth 1.0 days, where we had an HTML page that would print the oauth_verify code on the screen that the user would type into the application. These days, on most platforms, it’s much easier to register a custom URL handler or use another system service to get the code directly that this hack has all but disappeared, at least in my view. Can you give me a favor and clarify a bit what you mean when referring to a registered URL handler ? A user signs in, requests a code or a token for a specific client, AS returns it to the user directly. I guess it can redirect the user to some other web application which is where the user will interact and get the code or token. What a registered URL handler can change in this process, make it more automated ? (I understand working with the code is better in general...) Thanks, Sergey > > — Justin > >> On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin wrote: >> >> Hi All, >> >> We might have a requirement to support a case where AS returns an access token directly to a human user, with the user subsequently configuring a confidential client with this token. The actual client is not capable of supporting a (more dynamic) code flow at this stage. >> >> So it is nearly like an implicit code flow except that the user is asked upfront which clients can get the tokens allocated and the token is returned in the HTML response without redirecting and placing the token in a fragment. >> >> Apparently a number of big providers do just that, let users allocate tokens for some clients with the users expected to copy the tokens into the confidential clients afterwards. >> >> I'd like to ask, it is a reasonable approach, to have tokens transferred manually into the confidential client ? >> >> Would it be more appropriate for a user to request a code and then copy it to the confidential client and expect it to get the tokens itself. I guess the problem here may be a code is short lived, but so is a typical access token - but the latter can be supported by a refresh one. >> >> Another question: does it even qualify as an OAuth2 grant for token exchange, the process of a user pre-authorizing a client and getting not a code but tokens back ? I guess it does, so how a grant like this one would typically be called ? We'd have no problems with assigning some custom name to such a grant but curious how others approach it... >> >> Thanks, Sergey >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Fri Mar 6 14:47:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0711A1AA1 for ; Fri, 6 Mar 2015 14:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E-zdJ1Biz1zz for ; Fri, 6 Mar 2015 14:47:22 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE881A0AF1 for ; Fri, 6 Mar 2015 14:47:22 -0800 (PST) X-AuditID: 12074424-f79356d000004839-78-54fa2e799c09 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 61.D9.18489.97E2AF45; Fri, 6 Mar 2015 17:47:21 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t26MlKjj027590; Fri, 6 Mar 2015 17:47:20 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t26MlI6i002135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Mar 2015 17:47:19 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D03FCD37-6B21-46F6-A164-FAA7E1703F59"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Justin Richer In-Reply-To: <54FA2AD7.7000500@gmail.com> Date: Fri, 6 Mar 2015 17:47:17 -0500 Message-Id: <8E4D4A6C-A5CC-44E2-9AD3-7C9859F4D05C@mit.edu> References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <, > <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F9E246.70901@gmail.com> <52A4984A-5ACE-472D-986D-54012EB620C2@mit.edu> <54FA2AD7.7000500@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsUixG6nolup9yvE4NNrfouTb1+xWfxbau/A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZUz6uI254L1lxYVFzxkbGOfpdzFyckgImEhc mHyfHcIWk7hwbz1bFyMXh5DAYiaJi8f+sIIkhAQ2MEpceKoOkXjAJDFh9QomkISwgKPEgU0b WEBsXgEDibmnvjCBFDELTGKUuHP/AdRYKYkHt9cwgthsAqoS09e0gDVzCmhKbHrwEWwDi4CK xN7/F4HiHEDN6hLtJ10gZlpJ9O7azw6xuJVZYuPMyWBzRAS0JS6+vsUOUi8hIC/Rsyl9AqPg LCRnzEJ2BkiCGahl2cLXzBC2psT+7uUsELa8xPa3c6DilhKLZ96AittK3OpbwARh20k8mraI dQEjxypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73czBK91JTSTYzgyHFR2cHYfEjpEKMAB6MS D2+H1M8QIdbEsuLK3EOMkhxMSqK8F9V/hQjxJeWnVGYkFmfEF5XmpBYfYlQB2vVow+oLjFIs efl5qUoivFOVgep4UxIrq1KL8mHKpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwqukC NQoWpaanVqRl5pQgpJk4OA8xSnDwAA23AqnhLS5IzC3OTIfIn2JUlBLnfakDlBAASWSU5sH1 whLeK0ZxoLeEeTNA2nmAyRKu+xXQYCagwVpiP0AGlyQipKQaGKVMn/a12sz6n7IvaKtr/XKx a9U/V5nkFjxM0YkQ/KBWsELqx7XKXYXTkh7W7xB5zsFxzFDp+6f0m20TbaR+ZQUoLJz96FLQ jhbBKY/Fpk/be/LPn4zTyjraz3hKLmmvtjwUf0vNdsrTaZdutOZGVcgf//ahMP79o8jSyHbd 19/flCzTjE+tilViKc5INNRiLipOBADQ6oBXUwMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Returning tokens directly to a human user X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 22:47:25 -0000 --Apple-Mail=_D03FCD37-6B21-46F6-A164-FAA7E1703F59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 6, 2015, at 5:31 PM, Sergey Beryozkin = wrote: >=20 > Hi > On 06/03/15 18:28, Justin Richer wrote: >> All you=E2=80=99re really doing here is having a more manual and less = automated portion for part of the process. You=E2=80=99d want to do this = using a registered redirect URI that hosts the HTML page, and then = you=E2=80=99d need a control in the app itself where the user could = interact. >>=20 >> I would personally recommend using this approach to move an = authorization code manually instead of moving an access token. Assuming = your client can access the auth server directly (using the backchannel, = no browser), you should be able to POST to the token endpoint and get = the token directly without the user having to handle it. The reason = being that auth codes are client-limited and much more time-limited, and = their leakage doesn=E2=80=99t immediately lead to leakage of API access. >>=20 > Right now this is what I'm considering, whether to restrict it to the = client getting the tokens itself, with the inserted code, or indirectly, = after the user does it. We already support the former for public = clients, I guess in the latter case a token will also be linked to a = client because a user will enter a client id when requesting a token. >=20 > Just not sure yet if a 3rd party client will be 'prepared' as you say = to interact directly with AS, I guess it will be given that it is = expected it should be able to refresh=E2=80=A6 >=20 >=20 >> We had a similar approach with a limited client back in the OAuth 1.0 = days, where we had an HTML page that would print the oauth_verify code = on the screen that the user would type into the application. These days, = on most platforms, it=E2=80=99s much easier to register a custom URL = handler or use another system service to get the code directly that this = hack has all but disappeared, at least in my view. >=20 > Can you give me a favor and clarify a bit what you mean when referring = to a registered URL handler ? A user signs in, requests a code or a = token for a specific client, AS returns it to the user directly. I guess = it can redirect the user to some other web application which is where = the user will interact and get the code or token. What a registered URL = handler can change in this process, make it more automated ? (I = understand working with the code is better in general=E2=80=A6) I mean not doing anything special with the OAuth grants: use the = redirects that are already there, just do something special with the = page you=E2=80=99re redirected to that will display the code/token to = the user and instruct them to paste it into the client appropriately. It = can even be a pretty static page, with a bit of javascript to pull off = the return values. So you could build it like this: the user starts off at some webpage = that says =E2=80=9CAuthorize AppX=E2=80=9D and clicks that. This = redirects them to the authorization endpoint, just like normal. Note = that this redirect will include the client ID and scopes and all that, = just like normal. Then the user logs in, authorizes, and is redirected = back to AppX=E2=80=99s redirect_uri, just like normal. This redirect URI = will be on the same service that hosts the =E2=80=9Cstart off=E2=80=9D = page, if you want, so you can even check the =E2=80=9Cstate=E2=80=9D = value against a stored cookie or session for extra protection. That page = pops off the code or token parameter and displays it to the user, = telling them how to get it into the client. Once the code or token is in = the client, it goes on its way. This all works without changing OAuth at all, and the auth server and = resource server can be completely off-the-shelf. You=E2=80=99re = effectively splitting the client in half: there=E2=80=99s a web-based = half that deals with the authorization redirect, and a native half that = deals with the code/token swap and the protected API calls. You use a = person to glue them together. I=E2=80=99ve built this kind of thing before, and it works well until = people fall apart moving the displayed code between the web page and the = rest of the application. That=E2=80=99s why a lot of apps, where = possible, have just gone to popping up a browser. Dick=E2=80=99s = recommendation to look at settop boxes and other apps that *can=E2=80=99t*= pop up a browser is a good recommendation. =E2=80=94 Justin >=20 > Thanks, Sergey >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin = wrote: >>>=20 >>> Hi All, >>>=20 >>> We might have a requirement to support a case where AS returns an = access token directly to a human user, with the user subsequently = configuring a confidential client with this token. The actual client is = not capable of supporting a (more dynamic) code flow at this stage. >>>=20 >>> So it is nearly like an implicit code flow except that the user is = asked upfront which clients can get the tokens allocated and the token = is returned in the HTML response without redirecting and placing the = token in a fragment. >>>=20 >>> Apparently a number of big providers do just that, let users = allocate tokens for some clients with the users expected to copy the = tokens into the confidential clients afterwards. >>>=20 >>> I'd like to ask, it is a reasonable approach, to have tokens = transferred manually into the confidential client ? >>>=20 >>> Would it be more appropriate for a user to request a code and then = copy it to the confidential client and expect it to get the tokens = itself. I guess the problem here may be a code is short lived, but so is = a typical access token - but the latter can be supported by a refresh = one. >>>=20 >>> Another question: does it even qualify as an OAuth2 grant for token = exchange, the process of a user pre-authorizing a client and getting not = a code but tokens back ? I guess it does, so how a grant like this one = would typically be called ? We'd have no problems with assigning some = custom name to such a grant but curious how others approach it... >>>=20 >>> Thanks, Sergey >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_D03FCD37-6B21-46F6-A164-FAA7E1703F59 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJU+i52AAoJEDPAngkbd+w9dJ4H+wZQ41izKVuWI+ZlWIqm9XHJ l2jBZ8G5Aqvy3FX/QxEk2zpBufpDqs1obZM0SclRqv3dGzlM/tu6iJj7z8yRw4sa X24LmfKP/jCv1cG7IBwV/jeJvRTRXU6HcaCOgo9LsW8o45ghwrk0V5WXKRsbJXNO jfS8ycuibLNNVvMvTXDpoltyJ7wUbU2DB+yvoc0KFV6O+GtOvLjSRGBwQsKTXuJH eI9BB72z3Qfi/23gkGvrzGDoWg9ytnIIUkB0zwMqo1K8zz3I/jEgvBUtpuSxN06W ifSyXtZqmsM+R6vmDQ3UZofgJ2pqhMYOvweMneG0Xr1eS/fSnF2WdGJJGoF04PE= =KI+3 -----END PGP SIGNATURE----- --Apple-Mail=_D03FCD37-6B21-46F6-A164-FAA7E1703F59-- From nobody Fri Mar 6 15:01:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B181A1B22 for ; Fri, 6 Mar 2015 15:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xKqEsZtq6FN1 for ; Fri, 6 Mar 2015 15:01:29 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::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 8E30B1A01E7 for ; Fri, 6 Mar 2015 15:01:28 -0800 (PST) Received: by wevm14 with SMTP id m14so62314620wev.13 for ; Fri, 06 Mar 2015 15:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=M/GVIakaDfYsYBV5DXKagJmnBzd1TEOZSv04mWGhRVo=; b=fiEj2Hi5n8o8K/KYK8joskFuShk40IcWEJNcpNxlShWSO6O/fY3C89jKqC/z4u5jOH DJBii55NK2ugQmEDaebRNNprinxxcSglCilvzACeb+z+DFhzIw7rhcIWl05kFqcSGyrK f57fajYyY+D95aWpKAM4IhqD56++omKQFEoyfVGKhqb+xmwhhvaqeKcfqNOebMu0ZvT9 tOGIuCbI0ZQd7qbbBWYqHkdegsOut4nLXpSIzKSFrV8YgEqxjyrawUv5vxjhOxxCStc5 Q2Wp9Fmit2t2QjZku8PmvbpJPUDrGWfHxkcwNrGyEdgskS0OJi3aT174Qw96YEHnJf// FgcQ== X-Received: by 10.194.120.40 with SMTP id kz8mr34418365wjb.21.1425682887337; Fri, 06 Mar 2015 15:01:27 -0800 (PST) Received: from [192.168.2.7] ([89.100.10.58]) by mx.google.com with ESMTPSA id v5sm4181157wiw.24.2015.03.06.15.01.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 15:01:25 -0800 (PST) Message-ID: <54FA31C4.9030901@gmail.com> Date: Fri, 06 Mar 2015 23:01:24 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Richer References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com> <, > <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com> <54F9E246.70901@gmail.com> <52A4984A-5ACE-472D-986D-54012EB620C2@mit.edu> <54FA2AD7.7000500@gmail.com> <8E4D4A6C-A5CC-44E2-9AD3-7C9859F4D05C@mit.edu> In-Reply-To: <8E4D4A6C-A5CC-44E2-9AD3-7C9859F4D05C@mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Returning tokens directly to a human user X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 23:01:31 -0000 Hi Justin, Thanks for typing it all, appreciated... I guess the idea here is basically introduce a little web app 'intermediary' that will act as if it were a client except that it will show whatever it receives back from AS to the user. So we still have a common processing path at AS, as if it were a regular authorization code flow. I think I got it... Thanks for the advice - enjoy the weekends Sergey On 06/03/15 22:47, Justin Richer wrote: > >> On Mar 6, 2015, at 5:31 PM, Sergey Beryozkin wrote: >> >> Hi >> On 06/03/15 18:28, Justin Richer wrote: >>> All you’re really doing here is having a more manual and less automated portion for part of the process. You’d want to do this using a registered redirect URI that hosts the HTML page, and then you’d need a control in the app itself where the user could interact. >>> >>> I would personally recommend using this approach to move an authorization code manually instead of moving an access token. Assuming your client can access the auth server directly (using the backchannel, no browser), you should be able to POST to the token endpoint and get the token directly without the user having to handle it. The reason being that auth codes are client-limited and much more time-limited, and their leakage doesn’t immediately lead to leakage of API access. >>> >> Right now this is what I'm considering, whether to restrict it to the client getting the tokens itself, with the inserted code, or indirectly, after the user does it. We already support the former for public clients, I guess in the latter case a token will also be linked to a client because a user will enter a client id when requesting a token. >> >> Just not sure yet if a 3rd party client will be 'prepared' as you say to interact directly with AS, I guess it will be given that it is expected it should be able to refresh… > >> >> >>> We had a similar approach with a limited client back in the OAuth 1.0 days, where we had an HTML page that would print the oauth_verify code on the screen that the user would type into the application. These days, on most platforms, it’s much easier to register a custom URL handler or use another system service to get the code directly that this hack has all but disappeared, at least in my view. >> >> Can you give me a favor and clarify a bit what you mean when referring to a registered URL handler ? A user signs in, requests a code or a token for a specific client, AS returns it to the user directly. I guess it can redirect the user to some other web application which is where the user will interact and get the code or token. What a registered URL handler can change in this process, make it more automated ? (I understand working with the code is better in general…) > > I mean not doing anything special with the OAuth grants: use the redirects that are already there, just do something special with the page you’re redirected to that will display the code/token to the user and instruct them to paste it into the client appropriately. It can even be a pretty static page, with a bit of javascript to pull off the return values. > > So you could build it like this: the user starts off at some webpage that says “Authorize AppX” and clicks that. This redirects them to the authorization endpoint, just like normal. Note that this redirect will include the client ID and scopes and all that, just like normal. Then the user logs in, authorizes, and is redirected back to AppX’s redirect_uri, just like normal. This redirect URI will be on the same service that hosts the “start off” page, if you want, so you can even check the “state” value against a stored cookie or session for extra protection. That page pops off the code or token parameter and displays it to the user, telling them how to get it into the client. Once the code or token is in the client, it goes on its way. > > This all works without changing OAuth at all, and the auth server and resource server can be completely off-the-shelf. You’re effectively splitting the client in half: there’s a web-based half that deals with the authorization redirect, and a native half that deals with the code/token swap and the protected API calls. You use a person to glue them together. > > I’ve built this kind of thing before, and it works well until people fall apart moving the displayed code between the web page and the rest of the application. That’s why a lot of apps, where possible, have just gone to popping up a browser. Dick’s recommendation to look at settop boxes and other apps that *can’t* pop up a browser is a good recommendation. > > — Justin > > >> >> Thanks, Sergey >> >>> >>> — Justin >>> >>>> On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin wrote: >>>> >>>> Hi All, >>>> >>>> We might have a requirement to support a case where AS returns an access token directly to a human user, with the user subsequently configuring a confidential client with this token. The actual client is not capable of supporting a (more dynamic) code flow at this stage. >>>> >>>> So it is nearly like an implicit code flow except that the user is asked upfront which clients can get the tokens allocated and the token is returned in the HTML response without redirecting and placing the token in a fragment. >>>> >>>> Apparently a number of big providers do just that, let users allocate tokens for some clients with the users expected to copy the tokens into the confidential clients afterwards. >>>> >>>> I'd like to ask, it is a reasonable approach, to have tokens transferred manually into the confidential client ? >>>> >>>> Would it be more appropriate for a user to request a code and then copy it to the confidential client and expect it to get the tokens itself. I guess the problem here may be a code is short lived, but so is a typical access token - but the latter can be supported by a refresh one. >>>> >>>> Another question: does it even qualify as an OAuth2 grant for token exchange, the process of a user pre-authorizing a client and getting not a code but tokens back ? I guess it does, so how a grant like this one would typically be called ? We'd have no problems with assigning some custom name to such a grant but curious how others approach it... >>>> >>>> Thanks, Sergey >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > From nobody Sun Mar 8 20:06:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D851A07BD for ; Sun, 8 Mar 2015 20:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 VAvrM5vm1DZN for ; Sun, 8 Mar 2015 20:06:09 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22B11A03E1 for ; Sun, 8 Mar 2015 20:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2554; q=dns/txt; s=iport; t=1425870369; x=1427079969; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pcB+ELr+Dx3scrgiizNTtFj6BKD6uDmn7XDeHjnnjiI=; b=iAFxvlwHNAdfHUWRh6oSli1KKBcA//SItgH3+d5mxo9QMpJRg0S5bGzU Xk+14wzOsiFjhD6bS2CA7wId2vDUKIrjig72HICTtqqseWayOtYHhz09A wpcJyB0DKuaEJ1TYHqp2aDSY6IQBbGDL8lPunLpM7qvWGN899t0v9i6S/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BABQDRDf1U/5tdJa1agwZSXr9yaYE9DIVuAoEkOBQBAQEBAQEBfIQPAQEBBAEBATc0CwwEAgEIEQECAQEBCxQJBycLFAMGCAIEAQ0FCIgnDcEWAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sShD0xBwaDEYEUBYFMjiqDX4cAOYJmjxwjg25vAQGBQn8BAQE X-IronPort-AV: E=Sophos;i="5.11,365,1422921600"; d="scan'208";a="129981286" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 09 Mar 2015 03:06:09 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t29368Np021539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 03:06:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sun, 8 Mar 2015 22:06:08 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? Thread-Index: AQHQWD/GweO4O9/c5k2+8afKUY3J9Z0Tcdhg Date: Mon, 9 Mar 2015 03:06:07 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B1364@xmb-rcd-x10.cisco.com> References: <54F9CB3D.4000200@cs.tcd.ie> <54F9F932.7060701@gmx.net> In-Reply-To: <54F9F932.7060701@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.238] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 03:06:11 -0000 Hi Hannes, http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3= discusses long-term secret shared by the authorization server with the res= ource server but does not mention the out-of-band mechanism. In http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#sec= tion-4.1.1 we had provided three mechanisms for long-term key establishment= . In this use case RS and AS could be offered by the same provider (tightly= -coupled) or by different providers (loosely-coupled). Thoughts on which one should be mandatory to implement ? (This question came up in ISEG review and probably would be a question for = proof-of-possession work as well) Thanks and Regards, -Tiru > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Saturday, March 07, 2015 12:30 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? >=20 > Hi all, >=20 > does anyone have free cycles to review > draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in= a way > that is similar to the proof-of-possession work with a new access token f= ormat. >=20 > Ciao > Hannes >=20 > -------- Forwarded Message -------- > Subject: [saag] tram draft - anyone willing to help out? > Date: Fri, 06 Mar 2015 15:43:57 +0000 > From: Stephen Farrell > To: saag@ietf.org >=20 >=20 > Hiya, >=20 > There's a draft in IESG eval that attracted a bunch of perhaps fundamenta= l > discusses and comments [1] about its security properties. I think this ma= y be one > where the authors could do with a bit more help from the security > mafia^H^H^H^H^Hcommunity. > (I looked at their wg list and only see a v. thin smattering of names I'd= recognise > from this list.) So if you're willing and have a little time, please let = me know > and/or get in touch with the authors. >=20 > And btw - this might not seem so important but I'd worry it may end up be= ing a > major source of system level vulnerabilities for WebRTC deployments if we= get it > wrong and many sites don't deploy usefully good security for this bit of = the > WebRTC story. >=20 > Thanks in advance, > S. >=20 > [1] > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b= allot/ >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 >=20 From nobody Sun Mar 8 21:56:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8DF1A1EF6 for ; Sun, 8 Mar 2015 21:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Q1eCN8ugkiex for ; Sun, 8 Mar 2015 21:56:44 -0700 (PDT) Received: from nm40-vm4.bullet.mail.bf1.yahoo.com (nm40-vm4.bullet.mail.bf1.yahoo.com [72.30.239.212]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F341A1EF4 for ; Sun, 8 Mar 2015 21:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1425877003; bh=kLpPScPtjQCus4O+QIH3MAjkQO7WINmijD7HiNpMMG0=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=NZvj2Gm6QqfxyJn+WJS/fLrpZPWi8UET/Wl6vJE/AbDtihRe0dpDEyluzkyd5OVoJQjoB27ev6g4ufFe3YGyjC1R3UtrjQKj77h/WDTKW1Ca7YpPOZBy/4vZqvs4yg0FRI/8ZsGfc8tPA/+CZQMuhKJJWeTMRuyvEAPa0SwoVLrHdphvocsfPVInnlITB9ddrm0rW7y3IgTrDrBIeRYPnACquD9K0mn8QtItXdTAOIRnnrVSmZRBjI62UmUk3kFAc6wtKlQUZC9r490oM9HqzCpusjnlsRKZp7/drJyiXQjVomQbe4+MIqclR0pSN05X+15dMOanyXA57VvaVwzahA== Received: from [98.139.215.142] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 04:56:43 -0000 Received: from [98.139.212.210] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 04:56:43 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 04:56:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 69257.69058.bm@omp1019.mail.bf1.yahoo.com X-YMail-OSG: xRfFdIsVM1kv_FfIbHfHY8X_8Kj.haWpSVg_L1SC8Hv.ZvPjPkk08eF7k.Nyz5M wAX4QmwDBSoK9DupW04diqF6qbLldnCnV5bqkXvs7YrHBUMpuOHyc2__H4PG206RtxCJkSGa7vsr z6BlzaPTkHcxQU8ia080yMf1QjBwrdKrG98yzGROXz_JfTh7X7fObmsFkLFkR52cQDphyVFZ0LNT hPK38srA4Va2i1OzFVChnzvhbJcwdjsik7MvrGfpKjY30ZrC8ieKuREWpj1czgAEIDSLcJrgBw18 TcTi02DVR_3aQhAiQx5GvZQmxH0ysxnN7fv.RTM7t1NFU1V44.3dr_U6kycuUqRpkIXeG7IFVuNH 0rtwkB5oK0qG6sgcCIsQpvkfh9FSobxMf2SddO10zawbv7e6A4w5UQv4itKr2hW4xpx3aA1r3CiH WJgENDLG4PhEK43hFcZwBb9WHW0gtfA5j2CBpPEmMBJIndaHdp8PlGoTkpBpmII7F9C3aPGjJl_H qayEt7C7oikgjBuu_pmDA6y3JpZoKdelWbb5C7KaEnJtg Received: by 76.13.27.54; Mon, 09 Mar 2015 04:56:42 +0000 Date: Mon, 9 Mar 2015 04:56:42 +0000 (UTC) From: Bill Mills To: "Tirumaleswar Reddy (tireddy)" , Hannes Tschofenig , "oauth@ietf.org" Message-ID: <1820766683.1180885.1425877002127.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366B1364@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366B1364@xmb-rcd-x10.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1180884_206826374.1425877002121" Archived-At: Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 04:56:45 -0000 ------=_Part_1180884_206826374.1425877002121 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I do not believe making any specific key distribution MTI is aproprpiate. On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) wrote: Hi Hannes, http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 discusses long-term secret shared by the authorization server with the resource server but does not mention the out-of-band mechanism. In http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#section-4.1.1 we had provided three mechanisms for long-term key establishment. In this use case RS and AS could be offered by the same provider (tightly-coupled) or by different providers (loosely-coupled). Thoughts on which one should be mandatory to implement ? (This question came up in ISEG review and probably would be a question for proof-of-possession work as well) Thanks and Regards, -Tiru > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Saturday, March 07, 2015 12:30 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? > > Hi all, > > does anyone have free cycles to review > draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a way > that is similar to the proof-of-possession work with a new access token format. > > Ciao > Hannes > > -------- Forwarded Message -------- > Subject: [saag] tram draft - anyone willing to help out? > Date: Fri, 06 Mar 2015 15:43:57 +0000 > From: Stephen Farrell > To: saag@ietf.org > > > Hiya, > > There's a draft in IESG eval that attracted a bunch of perhaps fundamental > discusses and comments [1] about its security properties. I think this may be one > where the authors could do with a bit more help from the security > mafia^H^H^H^H^Hcommunity. > (I looked at their wg list and only see a v. thin smattering of names I'd recognise > from this list.) So if you're willing and have a little time, please let me know > and/or get in touch with the authors. > > And btw - this might not seem so important but I'd worry it may end up being a > major source of system level vulnerabilities for WebRTC deployments if we get it > wrong and many sites don't deploy usefully good security for this bit of the > WebRTC story. > > Thanks in advance, > S. > > [1] > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_1180884_206826374.1425877002121 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do not believe making any specific key di= stribution MTI is aproprpiate.

On Sunday, Ma= rch 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>= wrote:


Hi Hann= es,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01= #section-5.3 discusses long-term secret shared by the authorization ser= ver with the resource server but does not mention the out-of-band mechanism= .

In http://tools.ietf.org/html/draft-ietf-tram-turn-third-p= arty-authz-13#section-4.1.1 we had provided three mechanisms for long-t= erm key establishment. In this use case RS and AS could be offered by the s= ame provider (tightly-coupled) or by different providers (loosely-coupled).=

Thoughts on which one should be manda= tory to implement ?
(This question came up in ISEG review= and probably would be a question for proof-of-possession work as well)

Thanks and Regards,
-Ti= ru

> -----Original Message-----
> From: OA= uth [mailto:oauth-bounces@ietf.org] On Behalf O= f Hannes Tschofenig
> Sent: Saturday, March 07, 2015 1= 2:30 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to he= lp out?
>
> Hi all,
>
> does anyone have free cycles to review> draft-ietf-tram-turn-third-party-authz, which happens= to use OAuth 2.0 in a way
> that is similar to the pr= oof-of-possession work with a new access token format.
&g= t;
> Ciao
> Hannes
>
> -------- Forwarded Message --------
> Subject: [saag] tram draft - anyone willing to help out?<= br clear=3D"none">> Date: Fri, 06 Mar 2015 15:43:57 +0000
> From: Stephen Farrell <stephen.fa= rrell@cs.tcd.ie>
> To: saag@ietf.org = <saag@ietf.org>
>
&= gt;
> Hiya,
>
> There's a draft in IESG eval that attracted a bunch of perhaps fundam= ental
> discusses and comments [1] about its security = properties. I think this may be one
> where the author= s could do with a bit more help from the security
> ma= fia^H^H^H^H^Hcommunity.
> (I looked at their wg list a= nd only see a v. thin smattering of names I'd recognise
&= gt; from this list.) So if you're willing and have a little time, please le= t me know
> and/or get in touch with the authors.
>
> And btw - this might not seem so= important but I'd worry it may end up being a
> major= source of system level vulnerabilities for WebRTC deployments if we get it=
> wrong and many sites don't deploy usefully good sec= urity for this bit of the
> WebRTC story.
>
> Thanks in advance,
>= ; S.
>
> [1]
&= gt; https://datatracker.i= etf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/
>
> ________________________________________= _______
> saag mailing list
> saag@ietf.org
> https://www.ietf.o= rg/mailman/listinfo/saag
>
>=

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


------=_Part_1180884_206826374.1425877002121-- From nobody Sun Mar 8 22:24:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E32A1A3BA5 for ; Sun, 8 Mar 2015 22:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gTcOA14w1_L8 for ; Sun, 8 Mar 2015 22:24:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222F61A1B2C for ; Sun, 8 Mar 2015 22:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17214; q=dns/txt; s=iport; t=1425878685; x=1427088285; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+fLzJxYQrMvcFQ7L/gzypNQ2Opp380e7vROUCIMoskc=; b=msNCnpnClFLEhl2NnhZ5Yr8MiZs2KuzcAwyFz11fX4Gx7BrHQtNFa3ME eanM292HriCbT9Kf2++aFVNFBnsXj15Yw4pmkGTy0dEy1I7JHKT8qMlCe zjFlV0svBnwXj5QXECZUq579S72GM2zRZqgbKveqCd/+bJFntA7GjLLJg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6EABRLf1U/4gNJK1agkNDUloEgwavRI1DPIFwAQuFbgIcgQlNAQEBAQEBfIQPAQEBBAEBASAKQRcEAgEIDgMBAgEBAQsdAwICAiULEwEDBggCBAESCIgTAxENqCmbHgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLF4JEgXkWCg0KAQaCYi+BFgWBTIMkCosVg2SELYJcOYJviR+GEyODbm8BAYFCfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,365,1422921600"; d="scan'208,217";a="401919170" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 09 Mar 2015 05:24:44 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t295OiKo026633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 05:24:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 00:24:43 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Bill Mills , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? Thread-Index: AQHQWD/GweO4O9/c5k2+8afKUY3J9Z0TcdhggAB8WAD//7OEQA== Date: Mon, 9 Mar 2015 05:24:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B14BD@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366B1364@xmb-rcd-x10.cisco.com> <1820766683.1180885.1425877002127.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1820766683.1180885.1425877002127.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.238] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366B14BDxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 05:24:47 -0000 --_000_913383AAA69FF945B8F946018B75898A366B14BDxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmlsbCwNCg0KQ2FuIHlvdSBwbGVhc2UgcHJvdmlkZSBtb3JlIGRldGFpbHMgd2h5IG1hbmRh dGluZyBzcGVjaWZpYyBrZXkgZGlzdHJpYnV0aW9uIG1lY2hhbmlzbSBpcyBub3QgYXBwcm9wcmlh dGUgZXNwZWNpYWxseSBpbiBjYXNlIG9mIGxvb3NlbHkgY291cGxlZCBzeXN0ZW1zID8NCg0KLVRp cnUNCg0KRnJvbTogQmlsbCBNaWxscyBbbWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb21dDQpT ZW50OiBNb25kYXksIE1hcmNoIDA5LCAyMDE1IDEwOjI3IEFNDQpUbzogVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KTsgSGFubmVzIFRzY2hvZmVuaWc7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBGd2Q6IFtzYWFnXSB0cmFtIGRyYWZ0IC0gYW55b25lIHdpbGxpbmcg dG8gaGVscCBvdXQ/DQoNCkkgZG8gbm90IGJlbGlldmUgbWFraW5nIGFueSBzcGVjaWZpYyBrZXkg ZGlzdHJpYnV0aW9uIE1USSBpcyBhcHJvcHJwaWF0ZS4NCg0KT24gU3VuZGF5LCBNYXJjaCA4LCAy MDE1IDg6MDYgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28u Y29tPiB3cm90ZToNCg0KSGkgSGFubmVzLA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDEjc2VjdGlvbi01LjMgZGlzY3Vzc2Vz IGxvbmctdGVybSBzZWNyZXQgc2hhcmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aXRo IHRoZSByZXNvdXJjZSBzZXJ2ZXIgYnV0IGRvZXMgbm90IG1lbnRpb24gdGhlIG91dC1vZi1iYW5k IG1lY2hhbmlzbS4NCg0KSW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMTMjc2VjdGlvbi00LjEuMSB3ZSBoYWQgcHJvdmlk ZWQgdGhyZWUgbWVjaGFuaXNtcyBmb3IgbG9uZy10ZXJtIGtleSBlc3RhYmxpc2htZW50LiBJbiB0 aGlzIHVzZSBjYXNlIFJTIGFuZCBBUyBjb3VsZCBiZSBvZmZlcmVkIGJ5IHRoZSBzYW1lIHByb3Zp ZGVyICh0aWdodGx5LWNvdXBsZWQpIG9yIGJ5IGRpZmZlcmVudCBwcm92aWRlcnMgKGxvb3NlbHkt Y291cGxlZCkuDQoNClRob3VnaHRzIG9uIHdoaWNoIG9uZSBzaG91bGQgYmUgbWFuZGF0b3J5IHRv IGltcGxlbWVudCA/DQooVGhpcyBxdWVzdGlvbiBjYW1lIHVwIGluIElTRUcgcmV2aWV3IGFuZCBw cm9iYWJseSB3b3VsZCBiZSBhIHF1ZXN0aW9uIGZvciBwcm9vZi1vZi1wb3NzZXNzaW9uIHdvcmsg YXMgd2VsbCkNCg0KVGhhbmtzIGFuZCBSZWdhcmRzLA0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSGFubmVzIFRz Y2hvZmVuaWcNCj4gU2VudDogU2F0dXJkYXksIE1hcmNoIDA3LCAyMDE1IDEyOjMwIEFNDQo+IFRv OiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtPQVVU SC1XR10gRndkOiBbc2FhZ10gdHJhbSBkcmFmdCAtIGFueW9uZSB3aWxsaW5nIHRvIGhlbHAgb3V0 Pw0KPg0KPiBIaSBhbGwsDQo+DQo+IGRvZXMgYW55b25lIGhhdmUgZnJlZSBjeWNsZXMgdG8gcmV2 aWV3DQo+IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LCB3aGljaCBoYXBw ZW5zIHRvIHVzZSBPQXV0aCAyLjAgaW4gYSB3YXkNCj4gdGhhdCBpcyBzaW1pbGFyIHRvIHRoZSBw cm9vZi1vZi1wb3NzZXNzaW9uIHdvcmsgd2l0aCBhIG5ldyBhY2Nlc3MgdG9rZW4gZm9ybWF0Lg0K Pg0KPiBDaWFvDQo+IEhhbm5lcw0KPg0KPiAtLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0t LS0tLQ0KPiBTdWJqZWN0OiBbc2FhZ10gdHJhbSBkcmFmdCAtIGFueW9uZSB3aWxsaW5nIHRvIGhl bHAgb3V0Pw0KPiBEYXRlOiBGcmksIDA2IE1hciAyMDE1IDE1OjQzOjU3ICswMDAwDQo+IEZyb206 IFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTxtYWlsdG86c3RlcGhl bi5mYXJyZWxsQGNzLnRjZC5pZT4+DQo+IFRvOiBzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGll dGYub3JnPiA8c2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4+DQo+DQo+DQo+IEhp eWEsDQo+DQo+IFRoZXJlJ3MgYSBkcmFmdCBpbiBJRVNHIGV2YWwgdGhhdCBhdHRyYWN0ZWQgYSBi dW5jaCBvZiBwZXJoYXBzIGZ1bmRhbWVudGFsDQo+IGRpc2N1c3NlcyBhbmQgY29tbWVudHMgWzFd IGFib3V0IGl0cyBzZWN1cml0eSBwcm9wZXJ0aWVzLiBJIHRoaW5rIHRoaXMgbWF5IGJlIG9uZQ0K PiB3aGVyZSB0aGUgYXV0aG9ycyBjb3VsZCBkbyB3aXRoIGEgYml0IG1vcmUgaGVscCBmcm9tIHRo ZSBzZWN1cml0eQ0KPiBtYWZpYV5IXkheSF5IXkhjb21tdW5pdHkuDQo+IChJIGxvb2tlZCBhdCB0 aGVpciB3ZyBsaXN0IGFuZCBvbmx5IHNlZSBhIHYuIHRoaW4gc21hdHRlcmluZyBvZiBuYW1lcyBJ J2QgcmVjb2duaXNlDQo+IGZyb20gdGhpcyBsaXN0LikgU28gaWYgeW91J3JlIHdpbGxpbmcgYW5k IGhhdmUgYSBsaXR0bGUgdGltZSwgcGxlYXNlIGxldCBtZSBrbm93DQo+IGFuZC9vciBnZXQgaW4g dG91Y2ggd2l0aCB0aGUgYXV0aG9ycy4NCj4NCj4gQW5kIGJ0dyAtIHRoaXMgbWlnaHQgbm90IHNl ZW0gc28gaW1wb3J0YW50IGJ1dCBJJ2Qgd29ycnkgaXQgbWF5IGVuZCB1cCBiZWluZyBhDQo+IG1h am9yIHNvdXJjZSBvZiBzeXN0ZW0gbGV2ZWwgdnVsbmVyYWJpbGl0aWVzIGZvciBXZWJSVEMgZGVw bG95bWVudHMgaWYgd2UgZ2V0IGl0DQo+IHdyb25nIGFuZCBtYW55IHNpdGVzIGRvbid0IGRlcGxv eSB1c2VmdWxseSBnb29kIHNlY3VyaXR5IGZvciB0aGlzIGJpdCBvZiB0aGUNCj4gV2ViUlRDIHN0 b3J5Lg0KPg0KPiBUaGFua3MgaW4gYWR2YW5jZSwNCj4gUy4NCj4NCj4gWzFdDQo+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5 LWF1dGh6L2JhbGxvdC8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2FhZyBtYWlsaW5nIGxpc3QNCj4gc2FhZ0BpZXRmLm9yZzxtYWlsdG86 c2FhZ0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z YWFnDQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_913383AAA69FF945B8F946018B75898A366B14BDxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGkgQmlsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNhbiB5b3UgcGxlYXNlIHByb3ZpZGUg bW9yZSBkZXRhaWxzIHdoeSBtYW5kYXRpbmcgc3BlY2lmaWMga2V5IGRpc3RyaWJ1dGlvbiBtZWNo YW5pc20gaXMgbm90IGFwcHJvcHJpYXRlIGVzcGVjaWFsbHkgaW4gY2FzZSBvZiBsb29zZWx5IGNv dXBsZWQgc3lzdGVtcyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBCaWxsIE1pbGxzIFttYWlsdG86d21pbGxzXzkyMTA1QHlhaG9v LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDA5LCAyMDE1IDEwOjI3IEFN PGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBIYW5uZXMgVHNj aG9mZW5pZzsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gRndkOiBbc2FhZ10gdHJhbSBkcmFmdCAtIGFueW9uZSB3aWxsaW5nIHRvIGhlbHAgb3V0Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQy NTQxNzEwODg3OF81NjM0MzciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgZG8g bm90IGJlbGlldmUgbWFraW5nIGFueSBzcGVjaWZpYyBrZXkgZGlzdHJpYnV0aW9uIE1USSBpcyBh cHJvcHJwaWF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9uIFN1bmRheSwgTWFyY2ggOCwgMjAxNSA4OjA2IFBN LCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDt0aXJlZGR5QGNpc2NvLmNvbSZndDsg d3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgSGFubmVzLDxi cj4NCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtcG9wLWFyY2hpdGVjdHVyZS0wMSNzZWN0aW9uLTUuMyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVy ZS0wMSNzZWN0aW9uLTUuMw0KPC9hPmRpc2N1c3NlcyBsb25nLXRlcm0gc2VjcmV0IHNoYXJlZCBi eSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2l0aCB0aGUgcmVzb3VyY2Ugc2VydmVyIGJ1dCBk b2VzIG5vdCBtZW50aW9uIHRoZSBvdXQtb2YtYmFuZCBtZWNoYW5pc20uPGJyPg0KPGJyPg0KSW4g PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm4t dGhpcmQtcGFydHktYXV0aHotMTMjc2VjdGlvbi00LjEuMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHkt YXV0aHotMTMjc2VjdGlvbi00LjEuMQ0KPC9hPndlIGhhZCBwcm92aWRlZCB0aHJlZSBtZWNoYW5p c21zIGZvciBsb25nLXRlcm0ga2V5IGVzdGFibGlzaG1lbnQuIEluIHRoaXMgdXNlIGNhc2UgUlMg YW5kIEFTIGNvdWxkIGJlIG9mZmVyZWQgYnkgdGhlIHNhbWUgcHJvdmlkZXIgKHRpZ2h0bHktY291 cGxlZCkgb3IgYnkgZGlmZmVyZW50IHByb3ZpZGVycyAobG9vc2VseS1jb3VwbGVkKS48YnI+DQo8 YnI+DQpUaG91Z2h0cyBvbiB3aGljaCBvbmUgc2hvdWxkIGJlIG1hbmRhdG9yeSB0byBpbXBsZW1l bnQgPzxicj4NCihUaGlzIHF1ZXN0aW9uIGNhbWUgdXAgaW4gSVNFRyByZXZpZXcgYW5kIHByb2Jh Ymx5IHdvdWxkIGJlIGEgcXVlc3Rpb24gZm9yIHByb29mLW9mLXBvc3Nlc3Npb24gd29yayBhcyB3 ZWxsKTxicj4NCjxicj4NClRoYW5rcyBhbmQgUmVnYXJkcyw8YnI+DQotVGlydTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgaWQ9InlxdGZkMTQxMDciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0K Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogT0F1dGggW21h aWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCiZndDsg U2VudDogU2F0dXJkYXksIE1hcmNoIDA3LCAyMDE1IDEyOjMwIEFNPGJyPg0KJmd0OyBUbzogPGEg aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 IFN1YmplY3Q6IFtPQVVUSC1XR10gRndkOiBbc2FhZ10gdHJhbSBkcmFmdCAtIGFueW9uZSB3aWxs aW5nIHRvIGhlbHAgb3V0Pzxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBhbGwsPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IGRvZXMgYW55b25lIGhhdmUgZnJlZSBjeWNsZXMgdG8gcmV2aWV3PGJyPg0KJmd0 OyBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoeiwgd2hpY2ggaGFwcGVucyB0 byB1c2UgT0F1dGggMi4wIGluIGEgd2F5PGJyPg0KJmd0OyB0aGF0IGlzIHNpbWlsYXIgdG8gdGhl IHByb29mLW9mLXBvc3Nlc3Npb24gd29yayB3aXRoIGEgbmV3IGFjY2VzcyB0b2tlbiBmb3JtYXQu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENpYW88YnI+DQomZ3Q7IEhhbm5lczxicj4NCiZndDsgPGJy Pg0KJmd0OyAtLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLTxicj4NCiZndDsgU3Vi amVjdDogW3NhYWddIHRyYW0gZHJhZnQgLSBhbnlvbmUgd2lsbGluZyB0byBoZWxwIG91dD88YnI+ DQomZ3Q7IERhdGU6IEZyaSwgMDYgTWFyIDIwMTUgMTU6NDM6NTcgJiM0MzswMDAwPGJyPg0KJmd0 OyBGcm9tOiBTdGVwaGVuIEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPiZndDs8YnI+DQomZ3Q7 IFRvOiA8YSBocmVmPSJtYWlsdG86c2FhZ0BpZXRmLm9yZyI+c2FhZ0BpZXRmLm9yZzwvYT4gJmx0 OzxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPiZndDs8YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBIaXlhLDxicj4NCiZndDsgPGJyPg0KJmd0OyBU aGVyZSdzIGEgZHJhZnQgaW4gSUVTRyBldmFsIHRoYXQgYXR0cmFjdGVkIGEgYnVuY2ggb2YgcGVy aGFwcyBmdW5kYW1lbnRhbDxicj4NCiZndDsgZGlzY3Vzc2VzIGFuZCBjb21tZW50cyBbMV0gYWJv dXQgaXRzIHNlY3VyaXR5IHByb3BlcnRpZXMuIEkgdGhpbmsgdGhpcyBtYXkgYmUgb25lPGJyPg0K Jmd0OyB3aGVyZSB0aGUgYXV0aG9ycyBjb3VsZCBkbyB3aXRoIGEgYml0IG1vcmUgaGVscCBmcm9t IHRoZSBzZWN1cml0eTxicj4NCiZndDsgbWFmaWFeSF5IXkheSF5IY29tbXVuaXR5Ljxicj4NCiZn dDsgKEkgbG9va2VkIGF0IHRoZWlyIHdnIGxpc3QgYW5kIG9ubHkgc2VlIGEgdi4gdGhpbiBzbWF0 dGVyaW5nIG9mIG5hbWVzIEknZCByZWNvZ25pc2U8YnI+DQomZ3Q7IGZyb20gdGhpcyBsaXN0Likg U28gaWYgeW91J3JlIHdpbGxpbmcgYW5kIGhhdmUgYSBsaXR0bGUgdGltZSwgcGxlYXNlIGxldCBt ZSBrbm93PGJyPg0KJmd0OyBhbmQvb3IgZ2V0IGluIHRvdWNoIHdpdGggdGhlIGF1dGhvcnMuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEFuZCBidHcgLSB0aGlzIG1pZ2h0IG5vdCBzZWVtIHNvIGltcG9y dGFudCBidXQgSSdkIHdvcnJ5IGl0IG1heSBlbmQgdXAgYmVpbmcgYTxicj4NCiZndDsgbWFqb3Ig c291cmNlIG9mIHN5c3RlbSBsZXZlbCB2dWxuZXJhYmlsaXRpZXMgZm9yIFdlYlJUQyBkZXBsb3lt ZW50cyBpZiB3ZSBnZXQgaXQ8YnI+DQomZ3Q7IHdyb25nIGFuZCBtYW55IHNpdGVzIGRvbid0IGRl cGxveSB1c2VmdWxseSBnb29kIHNlY3VyaXR5IGZvciB0aGlzIGJpdCBvZiB0aGU8YnI+DQomZ3Q7 IFdlYlJUQyBzdG9yeS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGluIGFkdmFuY2UsPGJy Pg0KJmd0OyBTLjxicj4NCiZndDsgPGJyPg0KJmd0OyBbMV08YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJk LXBhcnR5LWF1dGh6L2JhbGxvdC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6L2Jh bGxvdC88L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzYWFnIG1haWxpbmcgbGlzdDxicj4NCiZn dDsgPGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciPnNhYWdAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWci IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nh YWc8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_913383AAA69FF945B8F946018B75898A366B14BDxmbrcdx10ciscoc_-- From nobody Sun Mar 8 22:39:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5399F1A6EF1 for ; Sun, 8 Mar 2015 22:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZyeaZ-q33rHd for ; Sun, 8 Mar 2015 22:39:41 -0700 (PDT) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEAA71A6FF7 for ; Sun, 8 Mar 2015 22:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1425879580; bh=sSqV4rrYYyDkykPShD74AAsrPtCtcH/VzCff9nr2ESc=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=B/aIsEU12jfTmZBfrK2yj5qOBMX9NIY/GcC/mt1loZunynWAanQeOLm8pOlxrPi/tYFdhQ9GSGEwg5BQjk9cwWflwqrcDWTaQ+AWTGxV502bNbAzo1S672AWSOZ+r6NOJpAjFW3ljxHPJtv4GOHC5hU5jcboPCIuTKAyJSx8QtCNyN83ea2Y5k8gChOP+6L2p22XOAWnomvSVccUIzuFKlsmvSIb4ZnMYBAUBIB1VpbDW62V7jJ2zyXVeV49vYumK4NLNLzs18Cg5Ps0CpeY5r7cBnBOk4yCdcpjRJ0FOUF9UCnWkxoPIh2EEsH0QI9YR2/XGU7VGzCot51pDuTg/Q== Received: from [66.196.81.173] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 05:39:40 -0000 Received: from [98.139.212.213] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 05:39:40 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 05:39:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 110214.40113.bm@omp1022.mail.bf1.yahoo.com X-YMail-OSG: gpD3_j4VM1nSHmRF9JNWB058nQ4fAIynDLOCisGIpsfktzI3K4TSavvwMENlfz2 hMuJ7kaBJpN0nam7vC8QCejNgx8VWKk2TLTWOxi9Yiv4L6cSzDceQV.ySV1Q9akVA7rxuTqBt9uk DnQofqkXr0_2HLrtGuSMq50rb9oN8421Qhpk7EphafkkcQLomSGDqjWKVXj5_cGZLEbDi1w59XHv Xohn0Rpoey4g0bDi8nmi9B4wl1fETl21MGv3RuzSDsJtb5AEkzMEj031MDKlTYhdvVyDkTvg.4E4 Dea_rFizloiP2wqcmRvXKgUW0l1Mp.BRyPhxV2m0QtJ6wZloxU_aDbpaoYZPEho.xj1GsU1S11iy NTy2d1Aq8vlGf.aJc0o.AONLlivwQMR5O6KLGXHl9r7Ny_9X4ic3Qxp4U3YqVItaKEkh5lg0FM6y .fjwrF_2bA_B3gC2na5Fd5.CrUNIzRji96djf7lMdsY2VHwH8Gj6I4F1vn0d3ZhvziL839oWMn_2 RCdxTMjtBh5wPEjR5LbhGxqj3Ya8.tRpdiWYiHKUNfM84 Received: by 76.13.26.137; Mon, 09 Mar 2015 05:39:39 +0000 Date: Mon, 9 Mar 2015 05:39:39 +0000 (UTC) From: Bill Mills To: "Tirumaleswar Reddy (tireddy)" , Hannes Tschofenig , "oauth@ietf.org" Message-ID: <370734452.1179117.1425879579160.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366B14BD@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366B14BD@xmb-rcd-x10.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1179116_1569807263.1425879579148" Archived-At: Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 05:39:43 -0000 ------=_Part_1179116_1569807263.1425879579148 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Explain to me why there should be one other than the desire to over-specify= ? =C2=A0Why is one so clearly superior to any of the various possibilities = that it should be mandated? I do not think that there is any clearly superior mechanism and so making a= ny particular one MTI is pointless and just likely to cause perfectly good = implementations to be out of spec.=20 On Sunday, March 8, 2015 10:24 PM, Tirumaleswar Reddy (tireddy) wrote: =20 #yiv3556672566 #yiv3556672566 -- _filtered #yiv3556672566 {font-family:Hel= vetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3556672566 {font-famil= y:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3556672566 {font-= family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv3556672566 {fo= nt-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv3556672566 #yiv35566725= 66 p.yiv3556672566MsoNormal, #yiv3556672566 li.yiv3556672566MsoNormal, #yiv= 3556672566 div.yiv3556672566MsoNormal {margin:0in;margin-bottom:.0001pt;fon= t-size:12.0pt;}#yiv3556672566 a:link, #yiv3556672566 span.yiv3556672566MsoH= yperlink {color:blue;text-decoration:underline;}#yiv3556672566 a:visited, #= yiv3556672566 span.yiv3556672566MsoHyperlinkFollowed {color:purple;text-dec= oration:underline;}#yiv3556672566 span.yiv3556672566EmailStyle17 {color:#1F= 497D;}#yiv3556672566 .yiv3556672566MsoChpDefault {} _filtered #yiv355667256= 6 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv3556672566 div.yiv3556672566WordSect= ion1 {}#yiv3556672566 Hi Bill, =C2=A0 Can you please provide more details = why mandating specific key distribution mechanism is not appropriate especi= ally in case of loosely coupled systems ? =C2=A0 -Tiru =C2=A0 From: Bill = Mills [mailto:wmills_92105@yahoo.com] Sent: Monday, March 09, 2015 10:27 AM To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out= ? =C2=A0 I do not believe making any specific key distribution MTI is apro= prpiate. =C2=A0 On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tire= ddy) wrote: =C2=A0 Hi Hannes, http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3= discusses long-term secret shared by the authorization server with the reso= urce server but does not mention the out-of-band mechanism. In http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#sec= tion-4.1.1we had provided three mechanisms for long-term key establishment.= In this use case RS and AS could be offered by the same provider (tightly-= coupled) or by different providers (loosely-coupled). Thoughts on which one should be mandatory to implement ? (This question came up in ISEG review and probably would be a question for = proof-of-possession work as well) Thanks and Regards, -Tiru=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Saturday, March 07, 2015 12:30 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? >=20 > Hi all, >=20 > does anyone have free cycles to review > draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in= a way > that is similar to the proof-of-possession work with a new access token f= ormat. >=20 > Ciao > Hannes >=20 > -------- Forwarded Message -------- > Subject: [saag] tram draft - anyone willing to help out? > Date: Fri, 06 Mar 2015 15:43:57 +0000 > From: Stephen Farrell > To: saag@ietf.org >=20 >=20 > Hiya, >=20 > There's a draft in IESG eval that attracted a bunch of perhaps fundamenta= l > discusses and comments [1] about its security properties. I think this ma= y be one > where the authors could do with a bit more help from the security > mafia^H^H^H^H^Hcommunity. > (I looked at their wg list and only see a v. thin smattering of names I'd= recognise > from this list.) So if you're willing and have a little time, please let = me know > and/or get in touch with the authors. >=20 > And btw - this might not seem so important but I'd worry it may end up be= ing a > major source of system level vulnerabilities for WebRTC deployments if we= get it > wrong and many sites don't deploy usefully good security for this bit of = the > WebRTC story. >=20 > Thanks in advance, > S. >=20 > [1] > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b= allot/ >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 >=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0=20 ------=_Part_1179116_1569807263.1425879579148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Explain to me why there should = be one other than the desire to over-specify?  Why is one so clearly s= uperior to any of the various possibilities that it should be mandated?
I do not think that there is a= ny clearly superior mechanism and so making any particular one MTI is point= less and just likely to cause perfectly good implementations to be out of s= pec.


On Sunday, March 8, 2015 10:24 PM, Tiru= maleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

#yiv3556672566 #yiv3556672566 -- =20 _filtered #yiv3556672566 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 = 2 4;} _filtered #yiv3556672566 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 = 2 4;} _filtered #yiv3556672566 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 = 4;} _filtered #yiv3556672566 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4= ;} #yiv3556672566 =20 #yiv3556672566 p.yiv3556672566MsoNormal, #yiv3556672566 li.yiv3556672566Mso= Normal, #yiv3556672566 div.yiv3556672566MsoNormal =09{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;} #yiv3556672566 a:link, #yiv3556672566 span.yiv3556672566MsoHyperlink =09{color:blue;text-decoration:underline;} #yiv3556672566 a:visited, #yiv3556672566 span.yiv3556672566MsoHyperlinkFoll= owed =09{color:purple;text-decoration:underline;} #yiv3556672566 span.yiv3556672566EmailStyle17 =09{color:#1F497D;} #yiv3556672566 .yiv3556672566MsoChpDefault =09{} _filtered #yiv3556672566 {margin:1.0in 1.0in 1.0in 1.0in;} #yiv3556672566 div.yiv3556672566WordSection1 =09{} #yiv3556672566
Hi = Bill,
=20
&n= bsp;
=20
Can= you please provide more details why mandating specific key distribution me= chanism is not appropriate especially in case of loosely coupled systems ?<= /span>
=20
&n= bsp;
=20
-Ti= ru
=20
&n= bsp;
=20
= From: Bill Mills [mailto:wmill= s_92105@yahoo.com]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org<= br clear=3D"none"> Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to h= elp out?
=20
 
=20
I do not believe making any specific key distributi= on MTI is aproprpiate.
=20
 
=20
On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Red= dy (tireddy) <tireddy@cisco.com> wrote:
=20
 
=20
Hi Hannes,

http://tools= .ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 discusses long-term secret shared by the authorization server with the = resource server but does not mention the out-of-band mechanism.

In http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#sectio= n-4.1.1 we had provided three mechanisms for long-term key establishment. In th= is use case RS and AS could be offered by the same provider (tightly-couple= d) or by different providers (loosely-coupled).

Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for = proof-of-possession work as well)

Thanks and Regards,
-Tiru
=20

> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help ou= t?
>
> Hi all,
>
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0= in a way
> that is similar to the proof-of-possession work with a new access toke= n format.
>
> Ciao
> Hannes
>
> -------- Forwarded Message --------
> Subject: [saag] tram draft - anyone willing to help out?
> Date: Fri, 06 Mar 2015 15:43:57 +0000
> From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
> To: saag@ietf.org <saag@ietf.org>
>
>
> Hiya,
>
> There's a draft in IESG eval that attracted a bunch of perhaps fundame= ntal
> discusses and comments [1] about its security properties. I think this= may be one
> where the authors could do with a bit more help from the security
> mafia^H^H^H^H^Hcommunity.
> (I looked at their wg list and only see a v. thin smattering of names = I'd recognise
> from this list.) So if you're willing and have a little time, please l= et me know
> and/or get in touch with the authors.
>
> And btw - this might not seem so important but I'd worry it may end up= being a
> major source of system level vulnerabilities for WebRTC deployments if= we get it
> wrong and many sites don't deploy usefully good security for this bit = of the
> WebRTC story.
>
> Thanks in advance,
> S.
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/bal= lot/
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/sa= ag
>
>

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


------=_Part_1179116_1569807263.1425879579148-- From nobody Sun Mar 8 22:48:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551711A700C for ; Sun, 8 Mar 2015 22:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1hYOV5z5YC8z for ; Sun, 8 Mar 2015 22:48:51 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DA61A7007 for ; Sun, 8 Mar 2015 22:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27690; q=dns/txt; s=iport; t=1425880131; x=1427089731; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Pe7jhJD5D0KVghuBvAy6uefG0uWayjegEKqm3mrw45I=; b=NMrt5k9swkOlInFOZb9gBtX3YFtmRMNtzyeNGldp38F60aXSDB1pg3EJ gxL1SLhh0gmwQ0w+JLGj3IHq1jcTWp4fbmo24AexSSjPiVecWcuNsWpZf yLcZ4vl4LI3r2s+FrMhZL5GGa3dGaH8l46C1UO8IIJWwTDUrSjd+SKz3F k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APDgBzM/1U/5tdJa1agkNDUloEgwavRI1DPIFwAQuFbgIcgQpNAQEBAQEBfIQPAQEBBAEBASAKQRcEAgEIDgMBAgEBAQsWBwMCAgIlCxMBAwYIAgQBEgiIEwMRDagcmxwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeCRIF5FgoNCgEGgmIvgRYFgUyDJAqLFYNkhC2CXDmCb4kfhhMjg25vAQGBQn8BAQE X-IronPort-AV: E=Sophos;i="5.11,365,1422921600"; d="scan'208,217";a="130050345" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 09 Mar 2015 05:48:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t295mo1b031347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 05:48:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 00:48:49 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Bill Mills , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? Thread-Index: AQHQWD/GweO4O9/c5k2+8afKUY3J9Z0TcdhggAB8WAD//7OEQIAAWHyA//+sriA= Date: Mon, 9 Mar 2015 05:48:48 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B1571@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366B14BD@xmb-rcd-x10.cisco.com> <370734452.1179117.1425879579160.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <370734452.1179117.1425879579160.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.238] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366B1571xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 05:48:57 -0000 --_000_913383AAA69FF945B8F946018B75898A366B1571xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhpcyB1c2UgY2FzZSBSUyBhbmQgQVMgY291bGQgYmUgaW1wbGVtZW50ZWQgYW5kIG9wZXJh dGVkIGJ5IGRpZmZlcmVudCBwcm92aWRlcnMsIE1USSBzb2x2ZXMgdGhlIGludGVyb3AgaXNzdWUu DQoNCi1UaXJ1DQoNCkZyb206IEJpbGwgTWlsbHMgW21haWx0bzp3bWlsbHNfOTIxMDVAeWFob28u Y29tXQ0KU2VudDogTW9uZGF5LCBNYXJjaCAwOSwgMjAxNSAxMToxMCBBTQ0KVG86IFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSk7IEhhbm5lcyBUc2Nob2ZlbmlnOyBvYXV0aEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gRndkOiBbc2FhZ10gdHJhbSBkcmFmdCAtIGFueW9uZSB3 aWxsaW5nIHRvIGhlbHAgb3V0Pw0KDQpFeHBsYWluIHRvIG1lIHdoeSB0aGVyZSBzaG91bGQgYmUg b25lIG90aGVyIHRoYW4gdGhlIGRlc2lyZSB0byBvdmVyLXNwZWNpZnk/ICBXaHkgaXMgb25lIHNv IGNsZWFybHkgc3VwZXJpb3IgdG8gYW55IG9mIHRoZSB2YXJpb3VzIHBvc3NpYmlsaXRpZXMgdGhh dCBpdCBzaG91bGQgYmUgbWFuZGF0ZWQ/DQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgdGhlcmUgaXMg YW55IGNsZWFybHkgc3VwZXJpb3IgbWVjaGFuaXNtIGFuZCBzbyBtYWtpbmcgYW55IHBhcnRpY3Vs YXIgb25lIE1USSBpcyBwb2ludGxlc3MgYW5kIGp1c3QgbGlrZWx5IHRvIGNhdXNlIHBlcmZlY3Rs eSBnb29kIGltcGxlbWVudGF0aW9ucyB0byBiZSBvdXQgb2Ygc3BlYy4NCg0KT24gU3VuZGF5LCBN YXJjaCA4LCAyMDE1IDEwOjI0IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIDx0aXJl ZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkgQmls bCwNCg0KQ2FuIHlvdSBwbGVhc2UgcHJvdmlkZSBtb3JlIGRldGFpbHMgd2h5IG1hbmRhdGluZyBz cGVjaWZpYyBrZXkgZGlzdHJpYnV0aW9uIG1lY2hhbmlzbSBpcyBub3QgYXBwcm9wcmlhdGUgZXNw ZWNpYWxseSBpbiBjYXNlIG9mIGxvb3NlbHkgY291cGxlZCBzeXN0ZW1zID8NCg0KLVRpcnUNCg0K RnJvbTogQmlsbCBNaWxscyBbbWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb21dDQpTZW50OiBN b25kYXksIE1hcmNoIDA5LCAyMDE1IDEwOjI3IEFNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KTsgSGFubmVzIFRzY2hvZmVuaWc7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEZ3ZDogW3NhYWddIHRyYW0gZHJhZnQg LSBhbnlvbmUgd2lsbGluZyB0byBoZWxwIG91dD8NCg0KSSBkbyBub3QgYmVsaWV2ZSBtYWtpbmcg YW55IHNwZWNpZmljIGtleSBkaXN0cmlidXRpb24gTVRJIGlzIGFwcm9wcnBpYXRlLg0KDQpPbiBT dW5kYXksIE1hcmNoIDgsIDIwMTUgODowNiBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQoN CkhpIEhhbm5lcywNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1wb3AtYXJjaGl0ZWN0dXJlLTAxI3NlY3Rpb24tNS4zIGRpc2N1c3NlcyBsb25nLXRlcm0gc2Vj cmV0IHNoYXJlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2l0aCB0aGUgcmVzb3VyY2Ug c2VydmVyIGJ1dCBkb2VzIG5vdCBtZW50aW9uIHRoZSBvdXQtb2YtYmFuZCBtZWNoYW5pc20uDQoN CkluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJk LXBhcnR5LWF1dGh6LTEzI3NlY3Rpb24tNC4xLjEgd2UgaGFkIHByb3ZpZGVkIHRocmVlIG1lY2hh bmlzbXMgZm9yIGxvbmctdGVybSBrZXkgZXN0YWJsaXNobWVudC4gSW4gdGhpcyB1c2UgY2FzZSBS UyBhbmQgQVMgY291bGQgYmUgb2ZmZXJlZCBieSB0aGUgc2FtZSBwcm92aWRlciAodGlnaHRseS1j b3VwbGVkKSBvciBieSBkaWZmZXJlbnQgcHJvdmlkZXJzIChsb29zZWx5LWNvdXBsZWQpLg0KDQpU aG91Z2h0cyBvbiB3aGljaCBvbmUgc2hvdWxkIGJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgPw0K KFRoaXMgcXVlc3Rpb24gY2FtZSB1cCBpbiBJU0VHIHJldmlldyBhbmQgcHJvYmFibHkgd291bGQg YmUgYSBxdWVzdGlvbiBmb3IgcHJvb2Ytb2YtcG9zc2Vzc2lvbiB3b3JrIGFzIHdlbGwpDQoNClRo YW5rcyBhbmQgUmVnYXJkcywNCi1UaXJ1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQo+IFNl bnQ6IFNhdHVyZGF5LCBNYXJjaCAwNywgMjAxNSAxMjozMCBBTQ0KPiBUbzogb2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbT0FVVEgtV0ddIEZ3ZDogW3Nh YWddIHRyYW0gZHJhZnQgLSBhbnlvbmUgd2lsbGluZyB0byBoZWxwIG91dD8NCj4NCj4gSGkgYWxs LA0KPg0KPiBkb2VzIGFueW9uZSBoYXZlIGZyZWUgY3ljbGVzIHRvIHJldmlldw0KPiBkcmFmdC1p ZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoeiwgd2hpY2ggaGFwcGVucyB0byB1c2UgT0F1 dGggMi4wIGluIGEgd2F5DQo+IHRoYXQgaXMgc2ltaWxhciB0byB0aGUgcHJvb2Ytb2YtcG9zc2Vz c2lvbiB3b3JrIHdpdGggYSBuZXcgYWNjZXNzIHRva2VuIGZvcm1hdC4NCj4NCj4gQ2lhbw0KPiBI YW5uZXMNCj4NCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gU3ViamVj dDogW3NhYWddIHRyYW0gZHJhZnQgLSBhbnlvbmUgd2lsbGluZyB0byBoZWxwIG91dD8NCj4gRGF0 ZTogRnJpLCAwNiBNYXIgMjAxNSAxNTo0Mzo1NyArMDAwMA0KPiBGcm9tOiBTdGVwaGVuIEZhcnJl bGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50 Y2QuaWU+Pg0KPiBUbzogc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4gPHNhYWdA aWV0Zi5vcmc8bWFpbHRvOnNhYWdAaWV0Zi5vcmc+Pg0KPg0KPg0KPiBIaXlhLA0KPg0KPiBUaGVy ZSdzIGEgZHJhZnQgaW4gSUVTRyBldmFsIHRoYXQgYXR0cmFjdGVkIGEgYnVuY2ggb2YgcGVyaGFw cyBmdW5kYW1lbnRhbA0KPiBkaXNjdXNzZXMgYW5kIGNvbW1lbnRzIFsxXSBhYm91dCBpdHMgc2Vj dXJpdHkgcHJvcGVydGllcy4gSSB0aGluayB0aGlzIG1heSBiZSBvbmUNCj4gd2hlcmUgdGhlIGF1 dGhvcnMgY291bGQgZG8gd2l0aCBhIGJpdCBtb3JlIGhlbHAgZnJvbSB0aGUgc2VjdXJpdHkNCj4g bWFmaWFeSF5IXkheSF5IY29tbXVuaXR5Lg0KPiAoSSBsb29rZWQgYXQgdGhlaXIgd2cgbGlzdCBh bmQgb25seSBzZWUgYSB2LiB0aGluIHNtYXR0ZXJpbmcgb2YgbmFtZXMgSSdkIHJlY29nbmlzZQ0K PiBmcm9tIHRoaXMgbGlzdC4pIFNvIGlmIHlvdSdyZSB3aWxsaW5nIGFuZCBoYXZlIGEgbGl0dGxl IHRpbWUsIHBsZWFzZSBsZXQgbWUga25vdw0KPiBhbmQvb3IgZ2V0IGluIHRvdWNoIHdpdGggdGhl IGF1dGhvcnMuDQo+DQo+IEFuZCBidHcgLSB0aGlzIG1pZ2h0IG5vdCBzZWVtIHNvIGltcG9ydGFu dCBidXQgSSdkIHdvcnJ5IGl0IG1heSBlbmQgdXAgYmVpbmcgYQ0KPiBtYWpvciBzb3VyY2Ugb2Yg c3lzdGVtIGxldmVsIHZ1bG5lcmFiaWxpdGllcyBmb3IgV2ViUlRDIGRlcGxveW1lbnRzIGlmIHdl IGdldCBpdA0KPiB3cm9uZyBhbmQgbWFueSBzaXRlcyBkb24ndCBkZXBsb3kgdXNlZnVsbHkgZ29v ZCBzZWN1cml0eSBmb3IgdGhpcyBiaXQgb2YgdGhlDQo+IFdlYlJUQyBzdG9yeS4NCj4NCj4gVGhh bmtzIGluIGFkdmFuY2UsDQo+IFMuDQo+DQo+IFsxXQ0KPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei9iYWxsb3Qv DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHNhYWcgbWFpbGluZyBsaXN0DQo+IHNhYWdAaWV0Zi5vcmc8bWFpbHRvOnNhYWdAaWV0Zi5vcmc+ DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KPg0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K --_000_913383AAA69FF945B8F946018B75898A366B1571xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAueWl2MzU1NjY3MjU2Nm1z b25vcm1hbCwgbGkueWl2MzU1NjY3MjU2Nm1zb25vcm1hbCwgZGl2LnlpdjM1NTY2NzI1NjZtc29u b3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzU1NjY3MjU2Nm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYzNTU2NjcyNTY2bXNv aHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnlpdjM1NTY2NzI1NjZtc29oeXBlcmxpbms7fQ0K c3Bhbi55aXYzNTU2NjcyNTY2bXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MzU1NjY3MjU2Nm1zb2h5cGVybGlua2ZvbGxvd2VkO30NCnNwYW4ueWl2MzU1NjY3MjU2NmVt YWlsc3R5bGUxNw0KCXttc28tc3R5bGUtbmFtZTp5aXYzNTU2NjcyNTY2ZW1haWxzdHlsZTE3O30N CnAueWl2MzU1NjY3MjU2Nm1zb25vcm1hbDEsIGxpLnlpdjM1NTY2NzI1NjZtc29ub3JtYWwxLCBk aXYueWl2MzU1NjY3MjU2Nm1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzU1NjY3MjU2 Nm1zb25vcm1hbDE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4ueWl2MzU1NjY3MjU2Nm1zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzU1 NjY3MjU2Nm1zb2h5cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4ueWl2MzU1NjY3MjU2Nm1zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXttc28t c3R5bGUtbmFtZTp5aXYzNTU2NjcyNTY2bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueWl2MzU1NjY3MjU2NmVt YWlsc3R5bGUxNzENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MzU1NjY3MjU2NmVtYWlsc3R5bGUxNzE7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4g dGhpcyB1c2UgY2FzZSBSUyBhbmQgQVMgY291bGQgYmUgaW1wbGVtZW50ZWQgYW5kIG9wZXJhdGVk IGJ5IGRpZmZlcmVudCBwcm92aWRlcnMsIE1USSBzb2x2ZXMgdGhlIGludGVyb3AgaXNzdWUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBCaWxsIE1pbGxzIFttYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIE1hcmNoIDA5LCAyMDE1IDExOjEwIEFNPGJyPg0KPGI+VG86PC9iPiBU aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBIYW5uZXMgVHNjaG9mZW5pZzsgb2F1dGhAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRndkOiBbc2FhZ10gdHJh bSBkcmFmdCAtIGFueW9uZSB3aWxsaW5nIHRvIGhlbHAgb3V0PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyNTQxNzEwODg3OF81NzY4NDci Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkV4cGxhaW4gdG8gbWUgd2h5IHRoZXJl IHNob3VsZCBiZSBvbmUgb3RoZXIgdGhhbiB0aGUgZGVzaXJlIHRvIG92ZXItc3BlY2lmeT8gJm5i c3A7V2h5IGlzIG9uZSBzbyBjbGVhcmx5IHN1cGVyaW9yIHRvIGFueSBvZiB0aGUgdmFyaW91cyBw b3NzaWJpbGl0aWVzDQogdGhhdCBpdCBzaG91bGQgYmUgbWFuZGF0ZWQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyNTQxNzEwODg3OF81Nzc0 ODIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjU0MTcxMDg4NzhfNTc2 ODQ1Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGRvIG5vdCB0aGluayB0aGF0 IHRoZXJlIGlzIGFueSBjbGVhcmx5IHN1cGVyaW9yIG1lY2hhbmlzbSBhbmQgc28gbWFraW5nIGFu eSBwYXJ0aWN1bGFyIG9uZSBNVEkgaXMgcG9pbnRsZXNzIGFuZCBqdXN0IGxpa2VseSB0byBjYXVz ZQ0KIHBlcmZlY3RseSBnb29kIGltcGxlbWVudGF0aW9ucyB0byBiZSBvdXQgb2Ygc3BlYy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPk9uIFN1bmRheSwgTWFyY2ggOCwgMjAxNSAxMDoyNCBQTSwgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIj50 aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgaWQ9InlpdjM1NTY2NzI1NjYiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBCaWxsLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5DYW4geW91IHBsZWFzZSBwcm92aWRlIG1vcmUgZGV0YWlscyB3aHkgbWFu ZGF0aW5nIHNwZWNpZmljIGtleSBkaXN0cmlidXRpb24gbWVjaGFuaXNtIGlzIG5vdCBhcHByb3By aWF0ZSBlc3BlY2lhbGx5IGluIGNhc2Ugb2YgbG9vc2VseQ0KIGNvdXBsZWQgc3lzdGVtcyA/PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi1UaXJ1PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 InlpdjM1NTY2NzI1NjZ5cXQwMTU1MCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+IEJpbGwgTWlsbHMgWzxhIGhyZWY9Im1haWx0bzp3bWlsbHNfOTIxMDVA eWFob28uY29tIj5tYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAwOSwgMjAxNSAxMDoyNyBBTTxicj4NCjxiPlRvOjwvYj4g VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgSGFubmVzIFRzY2hvZmVuaWc7IDxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+DQpvYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRndkOiBbc2FhZ10gdHJhbSBkcmFmdCAtIGFueW9uZSB3 aWxsaW5nIHRvIGhlbHAgb3V0Pzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IGlkPSJ5aXYzNTU2NjcyNTY2eXVpXzNfMTZfMF8xXzE0MjU0MTcxMDg4NzhfNTYzNDM3Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSBkbyBub3QgYmVsaWV2ZSBtYWtp bmcgYW55IHNwZWNpZmljIGtleSBkaXN0cmlidXRpb24gTVRJIGlzIGFwcm9wcnBpYXRlLjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+T24gU3VuZGF5LCBNYXJjaCA4LCAyMDE1IDg6MDYgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSI+dGlyZWRkeUBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpIEhhbm5lcyw8YnI+ DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLXBvcC1hcmNoaXRlY3R1cmUtMDEjc2VjdGlvbi01LjMiIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUt MDEjc2VjdGlvbi01LjMNCjwvYT5kaXNjdXNzZXMgbG9uZy10ZXJtIHNlY3JldCBzaGFyZWQgYnkg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHdpdGggdGhlIHJlc291cmNlIHNlcnZlciBidXQgZG9l cyBub3QgbWVudGlvbiB0aGUgb3V0LW9mLWJhbmQgbWVjaGFuaXNtLjxicj4NCjxicj4NCkluIDxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRo aXJkLXBhcnR5LWF1dGh6LTEzI3NlY3Rpb24tNC4xLjEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1 dGh6LTEzI3NlY3Rpb24tNC4xLjENCjwvYT53ZSBoYWQgcHJvdmlkZWQgdGhyZWUgbWVjaGFuaXNt cyBmb3IgbG9uZy10ZXJtIGtleSBlc3RhYmxpc2htZW50LiBJbiB0aGlzIHVzZSBjYXNlIFJTIGFu ZCBBUyBjb3VsZCBiZSBvZmZlcmVkIGJ5IHRoZSBzYW1lIHByb3ZpZGVyICh0aWdodGx5LWNvdXBs ZWQpIG9yIGJ5IGRpZmZlcmVudCBwcm92aWRlcnMgKGxvb3NlbHktY291cGxlZCkuPGJyPg0KPGJy Pg0KVGhvdWdodHMgb24gd2hpY2ggb25lIHNob3VsZCBiZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50 ID88YnI+DQooVGhpcyBxdWVzdGlvbiBjYW1lIHVwIGluIElTRUcgcmV2aWV3IGFuZCBwcm9iYWJs eSB3b3VsZCBiZSBhIHF1ZXN0aW9uIGZvciBwcm9vZi1vZi1wb3NzZXNzaW9uIHdvcmsgYXMgd2Vs bCk8YnI+DQo8YnI+DQpUaGFua3MgYW5kIFJlZ2FyZHMsPGJyPg0KLVRpcnU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9InlpdjM1NTY2NzI1NjZ5cXRmZDE0MTA3Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyBGcm9tOiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5d IE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCiZndDsgU2VudDogU2F0dXJkYXks IE1hcmNoIDA3LCAyMDE1IDEyOjMwIEFNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyBTdWJqZWN0OiBbT0FVVEgtV0ddIEZ3ZDogW3NhYWddIHRyYW0gZHJhZnQgLSBhbnlvbmUgd2ls bGluZyB0byBoZWxwIG91dD88YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgYWxsLDxicj4NCiZndDsg PGJyPg0KJmd0OyBkb2VzIGFueW9uZSBoYXZlIGZyZWUgY3ljbGVzIHRvIHJldmlldzxicj4NCiZn dDsgZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHosIHdoaWNoIGhhcHBlbnMg dG8gdXNlIE9BdXRoIDIuMCBpbiBhIHdheTxicj4NCiZndDsgdGhhdCBpcyBzaW1pbGFyIHRvIHRo ZSBwcm9vZi1vZi1wb3NzZXNzaW9uIHdvcmsgd2l0aCBhIG5ldyBhY2Nlc3MgdG9rZW4gZm9ybWF0 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXM8YnI+DQomZ3Q7IDxi cj4NCiZndDsgLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS08YnI+DQomZ3Q7IFN1 YmplY3Q6IFtzYWFnXSB0cmFtIGRyYWZ0IC0gYW55b25lIHdpbGxpbmcgdG8gaGVscCBvdXQ/PGJy Pg0KJmd0OyBEYXRlOiBGcmksIDA2IE1hciAyMDE1IDE1OjQzOjU3ICYjNDM7MDAwMDxicj4NCiZn dDsgRnJvbTogU3RlcGhlbiBGYXJyZWxsICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJy ZWxsQGNzLnRjZC5pZSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8 L2E+Jmd0Ozxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c2FhZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWFnQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2FhZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSGl5YSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlcmUncyBh IGRyYWZ0IGluIElFU0cgZXZhbCB0aGF0IGF0dHJhY3RlZCBhIGJ1bmNoIG9mIHBlcmhhcHMgZnVu ZGFtZW50YWw8YnI+DQomZ3Q7IGRpc2N1c3NlcyBhbmQgY29tbWVudHMgWzFdIGFib3V0IGl0cyBz ZWN1cml0eSBwcm9wZXJ0aWVzLiBJIHRoaW5rIHRoaXMgbWF5IGJlIG9uZTxicj4NCiZndDsgd2hl cmUgdGhlIGF1dGhvcnMgY291bGQgZG8gd2l0aCBhIGJpdCBtb3JlIGhlbHAgZnJvbSB0aGUgc2Vj dXJpdHk8YnI+DQomZ3Q7IG1hZmlhXkheSF5IXkheSGNvbW11bml0eS48YnI+DQomZ3Q7IChJIGxv b2tlZCBhdCB0aGVpciB3ZyBsaXN0IGFuZCBvbmx5IHNlZSBhIHYuIHRoaW4gc21hdHRlcmluZyBv ZiBuYW1lcyBJJ2QgcmVjb2duaXNlPGJyPg0KJmd0OyBmcm9tIHRoaXMgbGlzdC4pIFNvIGlmIHlv dSdyZSB3aWxsaW5nIGFuZCBoYXZlIGEgbGl0dGxlIHRpbWUsIHBsZWFzZSBsZXQgbWUga25vdzxi cj4NCiZndDsgYW5kL29yIGdldCBpbiB0b3VjaCB3aXRoIHRoZSBhdXRob3JzLjxicj4NCiZndDsg PGJyPg0KJmd0OyBBbmQgYnR3IC0gdGhpcyBtaWdodCBub3Qgc2VlbSBzbyBpbXBvcnRhbnQgYnV0 IEknZCB3b3JyeSBpdCBtYXkgZW5kIHVwIGJlaW5nIGE8YnI+DQomZ3Q7IG1ham9yIHNvdXJjZSBv ZiBzeXN0ZW0gbGV2ZWwgdnVsbmVyYWJpbGl0aWVzIGZvciBXZWJSVEMgZGVwbG95bWVudHMgaWYg d2UgZ2V0IGl0PGJyPg0KJmd0OyB3cm9uZyBhbmQgbWFueSBzaXRlcyBkb24ndCBkZXBsb3kgdXNl ZnVsbHkgZ29vZCBzZWN1cml0eSBmb3IgdGhpcyBiaXQgb2YgdGhlPGJyPg0KJmd0OyBXZWJSVEMg c3RvcnkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyBpbiBhZHZhbmNlLDxicj4NCiZndDsg Uy48YnI+DQomZ3Q7IDxicj4NCiZndDsgWzFdPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1h dXRoei9iYWxsb3QvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei9iYWxsb3QvPC9h Pjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgc2FhZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2FhZ0BpZXRmLm9yZzwv YT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2FhZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FhZzwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A366B1571xmbrcdx10ciscoc_-- From savitad.2007@googlemail.com Sun Mar 8 17:21:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436F01A036B for ; Sun, 8 Mar 2015 17:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.573 X-Spam-Level: * X-Spam-Status: No, score=1.573 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pdgdFuw_h4Rn for ; Sun, 8 Mar 2015 17:21:11 -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 285A61A0363 for ; Sun, 8 Mar 2015 17:21:11 -0700 (PDT) Received: by oiav63 with SMTP id v63so26472649oia.13 for ; Sun, 08 Mar 2015 17:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Xrg/+ZMGcG94P11t5bjsumqOEdx5hQV+bW1XA3eBRwo=; b=BzTeWgGAeytqI14gyUbLVttAmrURgKaXipEfyTpOWy3tleHbKYMlhIhkt1KojJj48x THz8b2TcDWXhktgrv3IBsBh8d0Ih4EQ1CNw3NRwtvxkJeK2sWBYLm1VO1hjVlKXMvHWK AeMy9kI/zRBzQLTvoqXd6bJ+pfdXUn/f7/asMrEbkozpbSq5+H09lv7SMAqDw4kpQ7zu V3F9cxwo5fNGIGqIRTDts3ddf2ehSIvsiWXzD0VqQ8eWScWcZSCsKcVLXsnsrGMYuGwd +CzeImfSRRV2uheqpB4VYSamZU7K15SDQdQLej0fTyi5WXXvldrvCK3nNL89L8wy1PLg BEOA== MIME-Version: 1.0 X-Received: by 10.60.45.200 with SMTP id p8mr19217347oem.46.1425860470636; Sun, 08 Mar 2015 17:21:10 -0700 (PDT) Received: by 10.202.227.131 with HTTP; Sun, 8 Mar 2015 17:21:10 -0700 (PDT) Date: Mon, 9 Mar 2015 01:21:10 +0100 Message-ID: From: Savita D To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c20ca0da06e50510d002bd Archived-At: X-Mailman-Approved-At: Mon, 09 Mar 2015 07:28:21 -0700 Subject: [OAUTH-WG] On Client credentials. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 00:25:54 -0000 --001a11c20ca0da06e50510d002bd Content-Type: text/plain; charset=UTF-8 Hi, Its really good to see this separation of authorization from application. While I was going through the spec, I could not understand the motive of client credentials. Why is there a Client credentials authorization grant? Please explain with some example. Thanks in advance. Savita. --001a11c20ca0da06e50510d002bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Its really good to see this separat= ion of authorization from application.
While I was going through = the spec, I could not understand the motive of client credentials.

Why is there a Client credentials authorization grant?=C2= =A0

Please=C2=A0explain with some example.

--001a11c20ca0da06e50510d002bd-- From nobody Mon Mar 9 07:31:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8E71A894C for ; Mon, 9 Mar 2015 07:31: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, SPF_PASS=-0.001] autolearn=ham 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 s5PYGRYDq0Hj for ; Mon, 9 Mar 2015 07:31:44 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::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 F1A881A8A48 for ; Mon, 9 Mar 2015 07:31:43 -0700 (PDT) Received: by iebtr6 with SMTP id tr6so30312386ieb.4 for ; Mon, 09 Mar 2015 07:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=u8BcbT6HFaY6vXlayccz0DL64BAta82WPFJra8kBKmk=; b=ecJVVwDXuaJ2hTXIUk1BEeP81dIqXI3ghOULeE+OUaRlpucJD+iLsemekpHyqFfGDx LsuotRXgHP0WjGNU17Fv+CAD4qhzZ5d1Du2U2eaEdDP9+Oque2z8Bo6GDPYkboqCKCKz /+XVutu+A1ebarHdpt1euAdwR4GnIC2ge3PNBhFk+Z77KV8G5rou2ahxX1t5eoEi5RJa 2QsOhO7MJt6KXNNkdqrLlzkQ4/jk5wnKd3iEqbZYca2bpFiN1rAzyj/88ZUwQpeCjVnq iSwIa4T7ewdryD60mvfPKyvygOQcoV8Mbej4CDC344x4Yu8c0rD9O7m8JipQkQpJ/BWY NXuQ== X-Received: by 10.50.171.170 with SMTP id av10mr74367169igc.28.1425911503240; Mon, 09 Mar 2015 07:31:43 -0700 (PDT) Received: from [192.168.1.65] (CPE84948c5cbf81-CM84948c5cbf80.cpe.net.cable.rogers.com. [99.224.188.56]) by mx.google.com with ESMTPSA id 13sm874405iok.29.2015.03.09.07.31.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 07:31:42 -0700 (PDT) Message-ID: <54FDAECD.1050406@gmail.com> Date: Mon, 09 Mar 2015 10:31:41 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050707080300010200090804" Archived-At: Subject: Re: [OAUTH-WG] On Client credentials. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 14:31:45 -0000 This is a multi-part message in MIME format. --------------050707080300010200090804 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Savita, the client credentials grant allows the Client to request an access token for *itself* (ie in its own right), rather than on behalf of a particular user (who is willing to delegate authorizations to the Client). paul On 3/8/15 8:21 PM, Savita D wrote: > Hi, > > Its really good to see this separation of authorization from application. > While I was going through the spec, I could not understand the motive > of client credentials. > > Why is there a Client credentials authorization grant? > > Please explain with some example. > > Thanks in advance. > Savita. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050707080300010200090804 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Savita, the client credentials grant allows the Client to request an access token for *itself* (ie in its own right), rather than on behalf of a particular user (who is willing to delegate authorizations to the Client).

paul

On 3/8/15 8:21 PM, Savita D wrote:
Hi,

Its really good to see this separation of authorization from application.
While I was going through the spec, I could not understand the motive of client credentials.

Why is there a Client credentials authorization grant? 

Please explain with some example.

Thanks in advance.
Savita.


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

--------------050707080300010200090804-- From nobody Mon Mar 9 09:32:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996D31A702A for ; Mon, 9 Mar 2015 09:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 7b9sOCrLz5CO for ; Mon, 9 Mar 2015 09:31:59 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4E61A8722 for ; Mon, 9 Mar 2015 09:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1425918718; bh=cNVGOGYE0IUV8EOhDKS2UVI6V71AxcBb47sYNhmZ1VQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Ocv/f5FT4hp+itootksLk+YBfQv2kYAbaLp0OPN1vDRkvlxlomuuCLVaX40Xha+qFDuciXoYt3d6EwnLKhX7rWG2VASeri09TfJwCmUQY7x4x8HTbR05eYFTO+2fkLgIZcp6Erxi56wIxoGJOCFpo7j+waFqs3DW/n7Y+Eh183R2DLk1mmLqjAHnii/sZv4qLp8MVi9ltetDeoHNiCXtZbiFEFXxITbrt2N3KzPPeU4JGvLzymYj985WkFpfzG997EnXjczx1i6Og2eKYyRvFclijRXT7n76RHuB3fOhWZT/jujPKrarX4kpMpMCD2DnUV/VVNkeqYim9xVtW5T1Ug== Received: from [66.196.81.173] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 16:31:58 -0000 Received: from [98.139.212.238] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 16:31:58 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 09 Mar 2015 16:31:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 298031.49025.bm@omp1047.mail.bf1.yahoo.com X-YMail-OSG: ptr4qSUVM1lzS2JZChZHFX0zAFYTE8VffBLb5yS_MR1ytdxA3qhrvweMcnOXy_4 a_r5T.ZsDcJ9glBKI.hBV5WiCafep9UFLJPlFyqtM0KVeMRpm3ULK08wv_.GFlePzzAl9kv.NgGz EJWkN8sdRPZ_sM3smHUqnJGqASsSGhh6AaMH2JYwNrRcThDGefs7EGuoN6LQTzry7_.6k0R.5RC0 wcVjEh5W6.uwh9iZdnoDpzAQOguvAXW57.cbvg.tudF.bmk5CeOrb0d7Pv_i2QM61ZMIFQwx7Pm6 O85lU7CePj28irmyrGoalKBGR.c128GX9kfkcTP1l_sLgYkXN4MZH3ry.Byei.P14gfP1mjK3.AI xVDEkYoEbx6jnHiF0J2FT1RfrmNaureY1V_92czPLM28Ss49ArsYHNUfaWlh0JtPRMR1Tm_xBhIZ 3k6n6uzR0iQwylymEhYeuLbfwjgDD8AOpCMH7AxpJniPxRsTqGabSRT50yXxhl35e8vMN9NatCUq gN0wiDGzxJfFckrL.ur2qTS8SEUS6Y9AoIO9x Received: by 66.196.81.111; Mon, 09 Mar 2015 16:31:57 +0000 Date: Mon, 9 Mar 2015 16:31:57 +0000 (UTC) From: Bill Mills To: "Tirumaleswar Reddy (tireddy)" , Hannes Tschofenig , "oauth@ietf.org" Message-ID: <111147053.1610787.1425918717427.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366B1571@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366B1571@xmb-rcd-x10.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1610786_725288088.1425918717414" Archived-At: Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:32:01 -0000 ------=_Part_1610786_725288088.1425918717414 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If this spec is about providing a single option for doing this as an option= that's fine. =C2=A0If it becomes MTI for using POP tokens at all =C2=A0thi= nk that's a mistake. =C2=A0 =C2=A0OAuth 2 provides a framework and one opti= onal token type, Bearer, which is not MTI. =C2=A0That's a reasonable thing = and would work here.=20 On Sunday, March 8, 2015 10:48 PM, Tirumaleswar Reddy (tireddy) wrote: =20 #yiv6169713675 #yiv6169713675 -- _filtered #yiv6169713675 {font-family:Hel= vetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6169713675 {font-famil= y:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6169713675 {font-= family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv6169713675 {fo= nt-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv6169713675 #yiv61697136= 75 p.yiv6169713675MsoNormal, #yiv6169713675 li.yiv6169713675MsoNormal, #yiv= 6169713675 div.yiv6169713675MsoNormal {margin:0in;margin-bottom:.0001pt;fon= t-size:12.0pt;}#yiv6169713675 a:link, #yiv6169713675 span.yiv6169713675MsoH= yperlink {color:blue;text-decoration:underline;}#yiv6169713675 a:visited, #= yiv6169713675 span.yiv6169713675MsoHyperlinkFollowed {color:purple;text-dec= oration:underline;}#yiv6169713675 p.yiv6169713675MsoAcetate, #yiv6169713675= li.yiv6169713675MsoAcetate, #yiv6169713675 div.yiv6169713675MsoAcetate {ma= rgin:0in;margin-bottom:.0001pt;font-size:8.0pt;}#yiv6169713675 p.yiv6169713= 675msonormal, #yiv6169713675 li.yiv6169713675msonormal, #yiv6169713675 div.= yiv6169713675msonormal {margin-right:0in;margin-left:0in;font-size:12.0pt;}= #yiv6169713675 span.yiv6169713675msohyperlink {}#yiv6169713675 span.yiv6169= 713675msohyperlinkfollowed {}#yiv6169713675 span.yiv6169713675emailstyle17 = {}#yiv6169713675 p.yiv6169713675msonormal1, #yiv6169713675 li.yiv6169713675= msonormal1, #yiv6169713675 div.yiv6169713675msonormal1 {margin:0in;margin-b= ottom:.0001pt;font-size:12.0pt;}#yiv6169713675 span.yiv6169713675msohyperli= nk1 {color:blue;text-decoration:underline;}#yiv6169713675 span.yiv616971367= 5msohyperlinkfollowed1 {color:purple;text-decoration:underline;}#yiv6169713= 675 span.yiv6169713675emailstyle171 {color:#1F497D;}#yiv6169713675 span.yiv= 6169713675BalloonTextChar {}#yiv6169713675 span.yiv6169713675EmailStyle27 {= color:#1F497D;}#yiv6169713675 .yiv6169713675MsoChpDefault {font-size:10.0pt= ;} _filtered #yiv6169713675 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv6169713675= div.yiv6169713675WordSection1 {}#yiv6169713675 In this use case RS and AS = could be implemented and operated by different providers, MTI solves the in= terop issue. =C2=A0 -Tiru =C2=A0 From: Bill Mills [mailto:wmills_92105@ya= hoo.com] Sent: Monday, March 09, 2015 11:10 AM To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out= ? =C2=A0 Explain to me why there should be one other than the desire to ov= er-specify? =C2=A0Why is one so clearly superior to any of the various poss= ibilities that it should be mandated? =C2=A0 I do not think that there is = any clearly superior mechanism and so making any particular one MTI is poin= tless and just likely to cause perfectly good implementations to be out of = spec. =C2=A0 On Sunday, March 8, 2015 10:24 PM, Tirumaleswar Reddy (tiredd= y) wrote: =C2=A0 Hi Bill, =C2=A0 Can you please provid= e more details why mandating specific key distribution mechanism is not app= ropriate especially in case of loosely coupled systems ? =C2=A0 -Tiru =C2= =A0 From: Bill Mills [mailto:wmills_92105@yahoo.com] Sent: Monday, March 09, 2015 10:27 AM To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out= ? =C2=A0 I do not believe making any specific key distribution MTI is aprop= rpiate. =C2=A0 On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tiredd= y) wrote: =C2=A0 Hi Hannes, http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3= discusses long-term secret shared by the authorization server with the reso= urce server but does not mention the out-of-band mechanism. In http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#sec= tion-4.1.1we had provided three mechanisms for long-term key establishment.= In this use case RS and AS could be offered by the same provider (tightly-= coupled) or by different providers (loosely-coupled). Thoughts on which one should be mandatory to implement ? (This question came up in ISEG review and probably would be a question for = proof-of-possession work as well) Thanks and Regards, -Tiru=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Saturday, March 07, 2015 12:30 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out? >=20 > Hi all, >=20 > does anyone have free cycles to review > draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in= a way > that is similar to the proof-of-possession work with a new access token f= ormat. >=20 > Ciao > Hannes >=20 > -------- Forwarded Message -------- > Subject: [saag] tram draft - anyone willing to help out? > Date: Fri, 06 Mar 2015 15:43:57 +0000 > From: Stephen Farrell > To: saag@ietf.org >=20 >=20 > Hiya, >=20 > There's a draft in IESG eval that attracted a bunch of perhaps fundamenta= l > discusses and comments [1] about its security properties. I think this ma= y be one > where the authors could do with a bit more help from the security > mafia^H^H^H^H^Hcommunity. > (I looked at their wg list and only see a v. thin smattering of names I'd= recognise > from this list.) So if you're willing and have a little time, please let = me know > and/or get in touch with the authors. >=20 > And btw - this might not seem so important but I'd worry it may end up be= ing a > major source of system level vulnerabilities for WebRTC deployments if we= get it > wrong and many sites don't deploy usefully good security for this bit of = the > WebRTC story. >=20 > Thanks in advance, > S. >=20 > [1] > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b= allot/ >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 >=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 =C2=A0=20 ------=_Part_1610786_725288088.1425918717414 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If this spec is about providing= a single option for doing this as an option that's fine.  If it becom= es MTI for using POP tokens at all  think that's a mistake.   &nb= sp;OAuth 2 provides a framework and one optional token type, Bearer, which = is not MTI.  That's a reasonable thing and would work here.


On Sunday, March 8, 2015 10:48 PM, Tirumaleswar Redd= y (tireddy) <tireddy@cisco.com> wrote:


<= div class=3D"y_msg_container">
In = this use case RS and AS could be implemented and operated by different prov= iders, MTI solves the interop issue.
=20
&n= bsp;
=20
-Ti= ru
=20
&n= bsp;
=20
= From: Bill Mills [mailto:wmill= s_92105@yahoo.com]
Sent: Monday, March 09, 2015 11:10 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org<= br clear=3D"none"> Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to h= elp out?
=20
 
=20
Explain to me why there should be one other than th= e desire to over-specify?  Why is one so clearly superior to any of th= e various possibilities that it should be mandated?
=20
 
=20
I do not think that there is any clearly superior m= echanism and so making any particular one MTI is pointless and just likely = to cause perfectly good implementations to be out of spec.
=20
 
=20
On Sunday, March 8, 2015 10:24 PM, Tirumaleswar Re= ddy (tireddy) <tireddy@= cisco.com> wrote:
=20
 
=20
Hi Bill,
=20
 
=20
Can you please provide more details why mandating = specific key distribution mechanism is not appropriate especially in case o= f loosely coupled systems ?
=20
 
=20
-Tiru
=20
 
=20
From: Bill Mills [= mailto:wmills_92105@yahoo.com]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to h= elp out?
=20
 
=20
I do not believe making any specific key distributi= on MTI is aproprpiate.
=20
 
=20
On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Red= dy (tireddy) <tireddy@c= isco.com> wrote:
=20
 
=20
Hi Hannes,

http://tools= .ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 discusses long-term secret shared by the authorization server with the = resource server but does not mention the out-of-band mechanism.

In http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#sectio= n-4.1.1 we had provided three mechanisms for long-term key establishment. In th= is use case RS and AS could be offered by the same provider (tightly-couple= d) or by different providers (loosely-coupled).

Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for = proof-of-possession work as well)

Thanks and Regards,
-Tiru
=20

> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help ou= t?
>
> Hi all,
>
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0= in a way
> that is similar to the proof-of-possession work with a new access toke= n format.
>
> Ciao
> Hannes
>
> -------- Forwarded Message --------
> Subject: [saag] tram draft - anyone willing to help out?
> Date: Fri, 06 Mar 2015 15:43:57 +0000
> From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
> To: saag@ietf.org <saag@ietf.org>
>
>
> Hiya,
>
> There's a draft in IESG eval that attracted a bunch of perhaps fundame= ntal
> discusses and comments [1] about its security properties. I think this= may be one
> where the authors could do with a bit more help from the security
> mafia^H^H^H^H^Hcommunity.
> (I looked at their wg list and only see a v. thin smattering of names = I'd recognise
> from this list.) So if you're willing and have a little time, please l= et me know
> and/or get in touch with the authors.
>
> And btw - this might not seem so important but I'd worry it may end up= being a
> major source of system level vulnerabilities for WebRTC deployments if= we get it
> wrong and many sites don't deploy usefully good security for this bit = of the
> WebRTC story.
>
> Thanks in advance,
> S.
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/bal= lot/
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/sa= ag
>
>

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


------=_Part_1610786_725288088.1425918717414-- From nobody Mon Mar 9 11:24:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1041A0072; Mon, 9 Mar 2015 11:24:11 -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] autolearn=ham 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 TzWDNrzae9c8; Mon, 9 Mar 2015 11:24:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3A71A88A5; Mon, 9 Mar 2015 11:24:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309182410.15118.45153.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 11:24:10 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:24:11 -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 Working Group of the IETF. Title : A Method for Signing an HTTP Requests for OAuth Authors : Justin Richer John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-signed-http-request-01.txt Pages : 11 Date : 2015-03-09 Abstract: This document a method for offering data origin authentication and integrity protection of HTTP requests. To convey the relevant data items in the request a JSON-based encapsulation is used and the JSON Web Signature (JWS) technique is re-used. JWS offers integrity protection using symmetric as well as asymmetric cryptography. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 12:13:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F1C1A9026; Mon, 9 Mar 2015 12:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 eApZsle5Lvtt; Mon, 9 Mar 2015 12:13:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D6D1A92DC; Mon, 9 Mar 2015 12:13:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150309191305.14394.97154.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 12:13:05 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Dynamic Client Registration Management Protocol) to Experimental RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:13:19 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Dynamic Client Registration Management Protocol' as Experimental RFC 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 2015-03-23. 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 methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Mar 9 16:28:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB9D1A8A84; Mon, 9 Mar 2015 16:28:07 -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] autolearn=ham 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 SoX33G6-szkm; Mon, 9 Mar 2015 16:28:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 311FC1ACDAE; Mon, 9 Mar 2015 16:28:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309232805.26630.37111.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 16:28:05 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:28:07 -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 Working Group of the IETF. Title : Proof-Of-Possession Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-02.txt Pages : 13 Date : 2015-03-09 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 16:34:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC961A90BC for ; Mon, 9 Mar 2015 16:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Jp8ywrTHnx56 for ; Mon, 9 Mar 2015 16:33:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33871A891E for ; Mon, 9 Mar 2015 16:33:56 -0700 (PDT) Received: from CO2PR03CA0035.namprd03.prod.outlook.com (10.141.194.162) by CY1PR0301MB0652.namprd03.prod.outlook.com (25.160.158.146) with Microsoft SMTP Server (TLS) id 15.1.99.9; Mon, 9 Mar 2015 23:33:55 +0000 Received: from BN1BFFO11FD001.protection.gbl (2a01:111:f400:7c10::1:122) by CO2PR03CA0035.outlook.office365.com (2a01:111:e400:1414::34) with Microsoft SMTP Server (TLS) id 15.1.99.9 via Frontend Transport; Mon, 9 Mar 2015 23:33:55 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD001.mail.protection.outlook.com (10.58.144.64) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Mon, 9 Mar 2015 23:33:55 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.148]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0224.003; Mon, 9 Mar 2015 23:33:51 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Proof-of-Possession draft -02 closing open issues Thread-Index: AdBawYCMYNDWzmg2TGGRUnaHTPJ3EQ== Date: Mon, 9 Mar 2015 23:33:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2F455FA@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2F455FATK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(438002)(209900001)(199003)(189002)(512954002)(2900100001)(106466001)(2930100002)(84326002)(6806004)(86362001)(110136001)(55846006)(92566002)(50986999)(54356999)(16297215004)(2920100001)(104016003)(19580395003)(19625215002)(2656002)(87936001)(229853001)(86612001)(33656002)(85806002)(107886001)(2351001)(102836002)(66066001)(230783001)(19300405004)(19617315012)(2501003)(16236675004)(46102003)(450100001)(62966003)(77156002)(1720100001)(15975445007)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0652; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0652; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001009); SRVR:CY1PR0301MB0652; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0652; X-Forefront-PRVS: 05102978A2 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2015 23:33:55.0308 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]; Helo=[mail.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0652 Archived-At: Subject: [OAUTH-WG] OAuth Proof-of-Possession draft -02 closing open issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:34:02 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943A2F455FATK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An updated OAuth Proof-of-Possession draft has been posted that address the= open issues identified in the previous draft. Changes were: * Defined the terms Issuer, Presenter, and Recipient and updated the= ir usage within the document. * Added a description of a use case using an asymmetric proof-of-pos= session key to the introduction. * Added the "kid" (key ID) confirmation method. Thanks to Hannes Tschofenig for writing text to address the open issues. This specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-= 02.html -- Mike P.S. This announcement was also posted at http://self-issued.info/?p=3D135= 4 and as @selfissued. --_000_4E1F6AAD24975D4BA5B1680429673943A2F455FATK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An updated OAuth Proof-of-Possession draft has been = posted that address the open issues identified in the previous draft. = Changes were:

·        Defined the terms Issuer, Presenter, and Rec= ipient and updated their usage within the document.

·        Added a description of a use case using an a= symmetric proof-of-possession key to the introduction.

·        Added the “kid” (key ID) confirmation method.

 

Thanks to Hannes Tschofenig for writing text to addr= ess the open issues.

 

This specification is available at:

·        http://tools.ietf.org/html/draft-ietf-oa= uth-proof-of-possession-02

 

An HTML formatted version is also available at:=

·        http://self-issued.info/docs/draf= t-ietf-oauth-proof-of-possession-02.html

 

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

 

P.S.  This announcement was also posted at http://self-issued.info/?p=3D1354 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B1680429673943A2F455FATK5EX14MBXC292r_-- From nobody Mon Mar 9 17:25:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CE61A8821 for ; Mon, 9 Mar 2015 17:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 xhbD07Lcbhtt for ; Mon, 9 Mar 2015 17:25:00 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003: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 9E6B31A01D8 for ; Mon, 9 Mar 2015 17:25:00 -0700 (PDT) Received: by oigi138 with SMTP id i138so32640938oig.4 for ; Mon, 09 Mar 2015 17:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=nkorWbAgImQ2bPThSYCAHr50bxq6+I5/2E+MVKpv94k=; b=G2BuYJZgW0qKa8aidCwDJyule66iy4un4rSJ5ATZlPf2Yy2e2HlSCV7N173s+9i63I 0kc6objgc6OI006DzoD/07pPP7lpsVGt+wCl6rhAFg8wlHqK3JBSM6E3oFasWaAny/0B 0qFLuw3avMpqyZadLK1zvZ9vOHTFMhr0eJfhbBte2bcykrS38kJVLQfWJIeJjv+ZuvHB S+Qa66ZgDaGzRXjwci6J9RJstX0v5jq4snrucQYix1amj6Dh53fCArAy/mQZ8aUdPzkT 2mrpE0r2OdxlvD3YMHcuzDtdiIRA9hJt9ZScDpDwJHrIf2HmAd66w4Vpqk0Ezn4eTPQX LxLw== X-Received: by 10.60.115.99 with SMTP id jn3mr24046142oeb.68.1425947100001; Mon, 09 Mar 2015 17:25:00 -0700 (PDT) MIME-Version: 1.0 References: <54C7BBA4.4030702@gmx.net> <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> <54E370F9.8060209@gmx.net> <17faabb6e724fb54f3cb8060a3d9cb08@lodderstedt.net> <54E4B0AD.10801@gmx.net> <54E4CCDD.6010709@gmx.net> From: Nat Sakimura Date: Tue, 10 Mar 2015 00:24:59 +0000 Message-ID: To: Brian Campbell , Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e0116126e5d39f20510e42eda Archived-At: Cc: oauth , "naa@google.com >> Naveen Agarwal" Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:25:02 -0000 --089e0116126e5d39f20510e42eda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Finally, we added PKCE S256 support on our implementation. Best, Nat 2015=E5=B9=B42=E6=9C=8820=E6=97=A5(=E9=87=91)=E3=80=817:28 Brian Campbell <= bcampbell@pingidentity.com>: > I can't comment with any authority on product road-map (that's above my > pay-grade) but I can speculate that we probably would support "S256" > eventually. > > On Wed, Feb 18, 2015 at 10:33 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Thanks Brian for pointing me to Section 4.4.1 and to the MTI for "S256". >> While this is good from a security point of view I am wondering whether >> anyone is actually compliant to the specification. Neither PingIdentity >> nor DT implements the S256 transform, if I understood that correctly. >> Are you guys going planning to update your implementations? >> >> Ciao >> Hannes >> >> On 02/18/2015 05:45 PM, Brian Campbell wrote: >> > There's a bit of MTI talk tucked into >> > https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 tha= t >> > perhaps needs to be expanded and/or placed somewhere else. >> > >> > On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig >> > > wrote: >> > >> > Thanks for the info, Torsten. >> > >> > Your feedback raises an interesting question, namely what >> functionality >> > the parties have to implement to claim conformance to the >> specification. >> > >> > Quickly scanning through the specification didn't tell me whether >> it is >> > OK to just implement the plain mode or whether both modes are >> > mandatory-to-implement. We have to say something about this. >> > >> > Ciao >> > Hannes >> > >> > >> > On 02/18/2015 02:16 PM, torsten@lodderstedt.net >> > wrote: >> > > Hi Hannes, >> > > >> > > our implementation supports the "plain" mode only. We just >> verified >> > > compliance of our implementation with the current spec. As the >> only >> > > deviation, we do not enforce the minimum length of 43 characters >> > of the >> > > code verifier. >> > > >> > > kind regards, >> > > Torsten. >> > > >> > > Am 17.02.2015 17:48, schrieb Hannes Tschofenig: >> > >> Hi Torsten, >> > >> >> > >> does this mean that your implementation is not compliant with t= he >> > >> current version anymore or that you haven't had time to verify >> > whether >> > >> there are differences to the earlier version? >> > >> >> > >> Ciao >> > >> Hannes >> > >> >> > >> >> > >> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote: >> > >>> Deutsche Telekom also implemented an early version of the draf= t >> last >> > >>> year. >> > >>> >> > >>> >> > >>> >> > >>> Am 30.01.2015 um 18:50 schrieb Brian Campbell >> > >>> >> > > > >>: >> > >>> >> > >>>> >> > >>>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig >> > >>>> >> > > > >> wrote: >> > >>>> >> > >>>> >> > >>>> 1) What implementations of the spec are you aware of? >> > >>>> >> > >>>> >> > >>>> We have an AS side implementation of an earlier draft that wa= s >> > >>>> released in June of last year: >> > >>>> >> > >> http://documentation.pingidentity.com/pages/viewpage.action?pageId=3D267= 06844 >> > >>>> >> > >>>> _______________________________________________ >> > >>>> 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 > --089e0116126e5d39f20510e42eda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Finally, we added PKCE S256 support on our implementation.

Best,
Nat
2015=E5=B9=B42=E6=9C=8820=E6=97=A5(= =E9=87=91)=E3=80=817:28 Brian Campbell <bcampbell@pingidentity.com>:
I can't comment with any authority on pr= oduct road-map (that's above my pay-grade) but I can speculate that we = probably would support "S256" eventually.

On Wed, Feb 18, 2015 at = 10:33 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Thanks Brian for pointing me t= o Section 4.4.1 and to the MTI for "S256".
While this is good from a security point of view I am wondering whether
anyone is actually compliant to the specification. Neither PingIdentity
nor DT implements the S256 transform, if I understood that correctly.
Are you guys going planning to update your implementations?

Ciao
Hannes

On 02/18/2015 05:45 PM, Brian Campbell wrote:
> There's a bit of MTI talk tucked into
> https://tools.ietf.org/html/draft-ietf-oauth-spo= p-10#section-4.4.1 that
> perhaps needs to be expanded and/or placed somewhere else.
>
> On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>&= gt; wrote:
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the info, Torsten.
>
>=C2=A0 =C2=A0 =C2=A0Your feedback raises an interesting question, namel= y what functionality
>=C2=A0 =C2=A0 =C2=A0the parties have to implement to claim conformance = to the specification.
>
>=C2=A0 =C2=A0 =C2=A0Quickly scanning through the specification didn'= ;t tell me whether it is
>=C2=A0 =C2=A0 =C2=A0OK to just implement the plain mode or whether both= modes are
>=C2=A0 =C2=A0 =C2=A0mandatory-to-implement. We have to say something ab= out this.
>
>=C2=A0 =C2=A0 =C2=A0Ciao
>=C2=A0 =C2=A0 =C2=A0Hannes
>
>
>=C2=A0 =C2=A0 =C2=A0On 02/18/2015 02:16 PM, torsten@lodderstedt.net
>=C2=A0 =C2=A0 =C2=A0<mailto:torsten@lodderstedt.net> wrote: >=C2=A0 =C2=A0 =C2=A0> Hi Hannes,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> our implementation supports the "plain&qu= ot; mode only. We just verified
>=C2=A0 =C2=A0 =C2=A0> compliance of our implementation with the curr= ent spec. As the only
>=C2=A0 =C2=A0 =C2=A0> deviation, we do not enforce the minimum lengt= h of 43 characters
>=C2=A0 =C2=A0 =C2=A0of the
>=C2=A0 =C2=A0 =C2=A0> code verifier.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> kind regards,
>=C2=A0 =C2=A0 =C2=A0> Torsten.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Am 17.02.2015 17:48, schrieb Hannes Tschofenig= :
>=C2=A0 =C2=A0 =C2=A0>> Hi Torsten,
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> does this mean that your implementation is= not compliant with the
>=C2=A0 =C2=A0 =C2=A0>> current version anymore or that you haven&= #39;t had time to verify
>=C2=A0 =C2=A0 =C2=A0whether
>=C2=A0 =C2=A0 =C2=A0>> there are differences to the earlier versi= on?
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Ciao
>=C2=A0 =C2=A0 =C2=A0>> Hannes
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On 01/31/2015 05:34 PM, Torsten Loddersted= t wrote:
>=C2=A0 =C2=A0 =C2=A0>>> Deutsche Telekom also implemented an e= arly version of the draft last
>=C2=A0 =C2=A0 =C2=A0>>> year.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Am 30.01.2015 um 18:50 schrieb Brian C= ampbell
>=C2=A0 =C2=A0 =C2=A0>>> <bcampbell@pingidentity.com <mailto:bcampbell@ping= identity.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:bcampbell@pingidentity.com
>=C2=A0 =C2=A0 =C2=A0<mailto:bcampbell@pingidentity.com>>>: >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On Tue, Jan 27, 2015 at 9:24 AM, H= annes Tschofenig
>=C2=A0 =C2=A0 =C2=A0>>>> <hannes.tschofenig@gmx.net <mailto:<= a href=3D"mailto:hannes.tschofenig@gmx.net" target=3D"_blank">hannes.tschof= enig@gmx.net>
>=C2=A0 =C2=A0 =C2=A0<mailto:hannes.tschofenig@gmx.net
>=C2=A0 =C2=A0 =C2=A0<mailto:hannes.tschofenig@gmx.net>>> wrot= e:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A01) What impleme= ntations of the spec are you aware of?
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> We have an AS side implementation = of an earlier draft that was
>=C2=A0 =C2=A0 =C2=A0>>>> released in June of last year:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0http://documentati= on.pingidentity.com/pages/viewpage.action?pageId=3D26706844
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> __________________________________= _____________
>=C2=A0 =C2=A0 =C2=A0>>>> OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:OAuth@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0>>>> https://www.ietf.org/mailman/listin= fo/oauth
>
>


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--089e0116126e5d39f20510e42eda-- From nobody Tue Mar 10 07:57:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2468F1A895B for ; Tue, 10 Mar 2015 07:57:22 -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_40=-0.001] autolearn=ham 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 dXJ_hib3PN78 for ; Tue, 10 Mar 2015 07:57:20 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C61E1A8953 for ; Tue, 10 Mar 2015 07:57:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0ACBEE2039 for ; Tue, 10 Mar 2015 10:57:19 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02041-10 for ; Tue, 10 Mar 2015 10:57:13 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C6AF8E2035 for ; Tue, 10 Mar 2015 10:57:13 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2AEvCev012848; Tue, 10 Mar 2015 10:57:12 -0400 From: Derek Atkins To: oauth@ietf.org Date: Tue, 10 Mar 2015 10:57:12 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [OAUTH-WG] WGLC for draft-ietf-oauth-proof-of-possession-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 14:57:22 -0000 Hi, I'd like to start a WGLC on draft-ietf-oauth-proof-of-possession-01. This will be a 2-week last call, so it will end on Tuesday, March 24 at 12 noon CDT. Keep in mind that the OAUTH meeting is Monday, March 23rd at 1300, so it would be BETTER if you could get your comments in before the meeting, but technically I need to keep the WGLC open until the 24th. Please send comments to the list. If you feel a comment cannot be sent to the list feel free to send it to the chairs privately and we can appropriately anonymize it for the list. Thanks! Only 13 days until our Dallas meeting. See you there! -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Mar 10 15:42:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158581A9051 for ; Tue, 10 Mar 2015 15:42:42 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0SGYswyoSmv7 for ; Tue, 10 Mar 2015 15:42:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B241A8F46 for ; Tue, 10 Mar 2015 15:42:39 -0700 (PDT) Received: from [192.168.10.132] ([208.85.208.52]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MfjJY-1Y8HfH0sQm-00NBaj; Tue, 10 Mar 2015 23:42:31 +0100 Message-ID: <54FF733E.4090907@gmx.net> Date: Tue, 10 Mar 2015 23:42:06 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Naveen Agarwal References: <54E372C1.8040204@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8uLicGnNm17ik5v6MlNtr8l9Qtghfk5ML" X-Provags-ID: V03:K0:BavFJJ+32phqHFZ4C172G8KYHxzBzbsJEaVDPuPvPuvV6xNte7Q pNSOC8mzgQOFjFJcGIhYqe20igp0EkSUz47NUg/3xlJ7nAA70WYPeGZeD1BTMvCQv68S/S2 k6YmmL0Slx6e8TbAJ2AgReb5vmf4bi2XMvn74dQKIguC4jkORQFnG2rdV4UgyWy0lmKX01v LFlewcQJZxi6yCbDE8G3A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 22:42:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8uLicGnNm17ik5v6MlNtr8l9Qtghfk5ML Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, Naveen! I will complete my shepherd write-up with this information. Ciao Hannes On 03/10/2015 07:33 PM, Naveen Agarwal wrote: >=20 > I definitely need the IPR confirmation. >=20 >=20 >=20 > I'm not aware of any IPR related tho this draft. >=20 >=20 > On Tue, Feb 17, 2015 at 8:56 AM, Hannes Tschofenig > > wrote: >=20 > Hi Nat, John, Naveen, >=20 > thanks a lot for your work on the document. >=20 > I still need responses to this mail to complete the shepherd writeu= p: > http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html >=20 > I definitely need the IPR confirmation. >=20 > It would also be helpful to have someone who implemented the > specification as it currently is. I asked Brian and Thorsten for > clarification regarding their statements that they implemented earl= ier > versions of the spec. >=20 > As a final remark I still believe that the text regarding the rando= mness > is still a bit inconsistent. Here are two examples: >=20 > 1) In the Security Consideration you write that "The security model= > relies on the fact that the code verifier is not learned or guessed= by > the attacker. It is vitally important to adhere to this principle.= " >=20 > 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD = have > enough entropy to make it impractical to guess the value. It is > RECOMMENDED that the output of a suitable random number generator b= e > used to create a 32-octet sequence." >=20 > There is clearly a long way from a SHOULD have enough entropy to th= e > text in the security consideration section where you ask for 32 byt= es > entropy. >=20 > It is also not clear why you ask for 32 bytes of entropy in particu= lar. >=20 > Ciao > Hannes >=20 >=20 --8uLicGnNm17ik5v6MlNtr8l9Qtghfk5ML Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU/3M+AAoJEGhJURNOOiAtOZQH/1ODZha9NDiKCmwpJ176QBzn posr7GAM9vniywrQ6yaohPSyn4b2VqrZKf7DEOYDsGvjy7MeazqRP3XyJLeTAT2d rrP/tyUSzZIfHeFcO/9pTbAC77YygbCB/55jWymbd93j3F8wybcPTjyspkAmZfdS uBkSdK1LcB2ElUmax000JmRCLfqymkvM/Krgw41PhySA4pDIC2Oj0+RgLgmjZk+D sVA9tvYdFtd7VbRoiQk+eUOAUE7FodbgHVAhTWK6Iu5qGZsDCxqUAV0z2itIk6NM VKD5f+rAEdxq4hudfhMH7014IhPSdwB9fwQdXh/OknB1CNhxVEnuebusfn1MXFQ= =l/ep -----END PGP SIGNATURE----- --8uLicGnNm17ik5v6MlNtr8l9Qtghfk5ML-- From nobody Tue Mar 10 22:26:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620F61A01D5 for ; Tue, 10 Mar 2015 22:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=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 4wbCdRMaDDUJ for ; Tue, 10 Mar 2015 22:26:52 -0700 (PDT) Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (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 6C2221A0121 for ; Tue, 10 Mar 2015 22:26:52 -0700 (PDT) Received: from pps.filterd (m0074419.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.14.7/8.14.7) with SMTP id t2B5OuDK002764 for ; Wed, 11 Mar 2015 00:26:51 -0500 Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by mx0b-0019e102.pphosted.com with ESMTP id 1t2eetg1nr-1 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 11 Mar 2015 00:26:51 -0500 Received: by qcwr17 with SMTP id r17so7779047qcw.2 for ; Tue, 10 Mar 2015 22:26:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6SlrvFGDYiJYUV3v6PxFfcz71Srt3wRQ0bmQAIdOw7I=; b=FvsUcVusY0ohlc03FRaNha6AxP6WeqhPiahqcVeG7JE1wqOZrOYkNlzOGIi1uKLiIK a34JY97lmokTTAclAqj2qaFS4gcSGHInJoEO4S14MZKASIZtz0ruJ6LOqYDGCsZl2+RN 98nyamd8mRHeeHgRG3IezgUr4+0Gs+81v/QqxvWjYJAK0eS9TL7gHhwkuDHFMhhke4X+ 1bLywue+O242izyVPYJxlHNWc/sD53fy84mIoIehbA+usMcwp2agHZ4AYgLJP+niW/ap FQOOyl8yng/Z/yVi+13CFcdQKuL46Y77e701bJa7b5NC4mhLUkiLqko2JwpFEcwP0uuP MLDQ== X-Gm-Message-State: ALoCoQnRkJ4RT0V0uqq8xRj4h0P1+hWqxLP/F58lpa6p3EEVEHUiClDTT5pNPVBWe6H7M8oKzEnzBIeUIbAWwguYIubCc/7cfXXjmleX4Dkwpl6DJkYo1Qw= X-Received: by 10.55.42.160 with SMTP id q32mr54407625qkq.68.1426051610988; Tue, 10 Mar 2015 22:26:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.42.160 with SMTP id q32mr54407614qkq.68.1426051610901; Tue, 10 Mar 2015 22:26:50 -0700 (PDT) Received: by 10.140.40.69 with HTTP; Tue, 10 Mar 2015 22:26:50 -0700 (PDT) Date: Wed, 11 Mar 2015 00:26:50 -0500 Message-ID: From: Adam Lewis To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11494136b314780510fc83eb X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=5.37785371790278e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.640908082233313 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.640908082233313 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.640908082233313 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503110060 Archived-At: Subject: [OAUTH-WG] Motivation for OAuth 2.0 Dynamic Client Registration Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 05:26:54 -0000 --001a11494136b314780510fc83eb Content-Type: text/plain; charset=UTF-8 Hi, I am curious about the use cases that inspired this draft, as the terminology that is defined within fits like a glove a use case that I have, though the draft doesn't solve it it completely. Namely the use case as I have is for the "client developer" to be able to create a developer account with the "software API publisher" via developer portal, and to then make their client available for download on an app store (e.g. Google Play), where it would be downloaded by a "deployment organization" and finally run the client registration protocol. This fits our use case 90%, but we have a further use case that the "software API deployment" is able to identify the "client developer" of the application when executing in a "deployment organization." I'm curious if that last part was ever identified as a use case for the draft? tx adam --001a11494136b314780510fc83eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am curious about the use cases th= at inspired this draft, as the terminology that is defined within fits like= a glove a use case that I have, though the draft doesn't solve it it c= ompletely.

Namely the use case as I have is for th= e "client developer" to be able to create a developer account wit= h the "software API publisher" via =C2=A0developer portal, and to= then make their client available for download on an app store (e.g. Google= Play), where it would be downloaded by a "deployment organization&quo= t; and finally run the client registration protocol.=C2=A0 This fits our us= e case 90%, but we have a further use case that the "software API depl= oyment" is able to identify the "client developer" of the ap= plication when executing in a "deployment organization."=C2=A0

I'm curious if that last part was ever identifie= d as a use case for the draft?



=
tx
adam
--001a11494136b314780510fc83eb-- From nobody Wed Mar 11 05:04:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281511A88B1 for ; Wed, 11 Mar 2015 05:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZEE5P4nOZcyp for ; Wed, 11 Mar 2015 05:04:10 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5463A1A8843 for ; Wed, 11 Mar 2015 05:04:10 -0700 (PDT) X-AuditID: 1209190e-f79bb6d0000030e8-7d-55002f385e96 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 17.F7.12520.83F20055; Wed, 11 Mar 2015 08:04:09 -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 t2BC47gl031080; Wed, 11 Mar 2015 08:04:08 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BC45s0021913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 08:04:07 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_ED485F67-0F8D-49C1-B3FE-18D52D1DB62C"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Justin Richer In-Reply-To: Date: Wed, 11 Mar 2015 08:04:04 -0400 Message-Id: <7CDF2772-18FA-46EE-9E65-8D2740460FD1@mit.edu> References: To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsUixG6nrmupzxBq0PqJ0WLntp+sFiffvmJz YPJYsuQnk8eEiT9YApiiuGxSUnMyy1KL9O0SuDIOHj3EXNBgUXFh1R2WBsaNBl2MnBwSAiYS B5f8ZYKwxSQu3FvP1sXIxSEksJhJYubXiywgCSGBjYwSL067QyQeMkk0Lv3OCJIQFgiVWHHi PJjNK2AgMffUFyaQImaBSYwSN/bcY4EYKyXx4PYasCI2AVWJ6WtawNZxCgRKHHp1jhnEZgGK P5q1jL2LkQOoWV2i/aQLxEwriX1fdrFBHBEg0brqGNgYEQELia0vrzCBlEsIyEv0bEqfwCg4 C8kVs5BdMQtsapLErZ8yIDXMAtoSyxa+ZoawNSX2dy9nwRTXkOj8NpEVwpaX2P52DlTcUmLx zBtQ9bYSt/oWMEHYdhKPpi1iXcDIvYpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0 EyMo/jgl+XYwfj2odIhRgINRiYd3xqz/IUKsiWXFlbmHGCU5mJREeS/qMIQK8SXlp1RmJBZn xBeV5qQWH2JUAdr1aMPqC4xSLHn5ealKIrynVYHqeFMSK6tSi/JhyqQ5WJTEeTf94AsREkhP LEnNTk0tSC2CycpwcChJ8FbqAjUKFqWmp1akZeaUIKSZODgPMUpw8AANTwOp4S0uSMwtzkyH yJ9iVJQS530Acp0ASCKjNA+uF5Y2XzGKA70lzOsBUsUDTLlw3a+ABjMBDWaxBnqYt7gkESEl 1cCos5GPaaKie1uR4pPKuJbiB0u37Zh4auvmDsY9Hn0+GxoXBW46vEfMXlxPmd/ph0DovfId B9Ruv9xhKLZfa6lqZtb8uzI8PFIf4jQP/8k+7NXJwr98zvl9fOzZB/YK5Lzl/7Lk9dSSb7FX nTrbxeYJGDGd3nn8qnndxRvztm2865y1ryA5e9UnJZbijERDLeai4kQA4mj4dHYDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Motivation for OAuth 2.0 Dynamic Client Registration Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 12:04:13 -0000 --Apple-Mail=_ED485F67-0F8D-49C1-B3FE-18D52D1DB62C Content-Type: multipart/alternative; boundary="Apple-Mail=_DB4909F1-6FD9-4606-9563-4F260CC48256" --Apple-Mail=_DB4909F1-6FD9-4606-9563-4F260CC48256 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adam, Yes, in fact that use case is the motivation behind allowing the initial = access token mechanism, where the developer goes and gets a = pre-registration token and passes that in through the application = itself: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendix-A.1.2 = What we don=E2=80=99t specify is *how* the deployment organization finds = out about the client developer, since that=E2=80=99s so far been = something that=E2=80=99s pretty tightly tied in to deployments. In = BlueButton+ we used a combination of a structured initial access tokens = and a registry service (think of it like a trust root with discovery = components) to get this kind of information across the wire. Within your = deployment umbrella you could do something similar, or use the software = statement mechanism to carry similar information. Nobody=E2=80=99s = sought to have that specific part standardized yet, but you can = absolutely deploy it within the Dynamic Client Registration spec. =E2=80=94 Justin > On Mar 11, 2015, at 1:26 AM, Adam Lewis = wrote: >=20 > Hi, >=20 > I am curious about the use cases that inspired this draft, as the = terminology that is defined within fits like a glove a use case that I = have, though the draft doesn't solve it it completely. >=20 > Namely the use case as I have is for the "client developer" to be able = to create a developer account with the "software API publisher" via = developer portal, and to then make their client available for download = on an app store (e.g. Google Play), where it would be downloaded by a = "deployment organization" and finally run the client registration = protocol. This fits our use case 90%, but we have a further use case = that the "software API deployment" is able to identify the "client = developer" of the application when executing in a "deployment = organization." >=20 > I'm curious if that last part was ever identified as a use case for = the draft? >=20 >=20 >=20 > tx > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DB4909F1-6FD9-4606-9563-4F260CC48256 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Adam,

Yes, in fact that use case is the motivation behind allowing = the initial access token mechanism, where the developer goes and gets a = pre-registration token and passes that in through the application = itself:

https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendi= x-A.1.2

What= we don=E2=80=99t specify is *how* the deployment organization finds out = about the client developer, since that=E2=80=99s so far been something = that=E2=80=99s pretty tightly tied in to deployments. In BlueButton+ we = used a combination of a structured initial access tokens and a registry = service (think of it like a trust root with discovery components) to get = this kind of information across the wire. Within your deployment = umbrella you could do something similar, or use the software statement = mechanism to carry similar information. Nobody=E2=80=99s sought to have = that specific part standardized yet, but you can absolutely deploy it = within the Dynamic Client Registration spec.

 =E2=80=94 Justin

On Mar 11, 2015, at 1:26 AM, Adam Lewis <Adam.Lewis@motorolasolutions.com> wrote:

Hi,

I am curious about the use cases that = inspired this draft, as the terminology that is defined within fits like = a glove a use case that I have, though the draft doesn't solve it it = completely.

Namely the use case as I have is for the "client developer" = to be able to create a developer account with the "software API = publisher" via  developer portal, and to then make their client = available for download on an app store (e.g. Google Play), where it = would be downloaded by a "deployment organization" and finally run the = client registration protocol.  This fits our use case 90%, but we = have a further use case that the "software API deployment" is able to = identify the "client developer" of the application when executing in a = "deployment organization." 

I'm curious if that last part was ever = identified as a use case for the draft?



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

= --Apple-Mail=_DB4909F1-6FD9-4606-9563-4F260CC48256-- --Apple-Mail=_ED485F67-0F8D-49C1-B3FE-18D52D1DB62C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJVAC81AAoJEDPAngkbd+w9l7kH/R8Rwr1DDfid6tuVw6JX0xwK VCXzdIpmrc+ahUCZJUz6Nq5XloGeRWtUDW59iBrrTut026bV34MqM5K9ZtR+0Kxs 4DqZYiqafJt5EOdZO+Z2G9CS+N/u3NvJS1vEO5ngfmaTu6V9x7RDz7KRGIlKepl4 xHBbsY5gO6M9GHQUMZUzTmd9+UY3PQdlziPfTU4Jtol5/M1dimYimwWq0da05rJt B0bemvLEfzklqKVaH6Z87ceXweKEfET41aXVBp/EMcVa91pgsAa5VDCGF1L9WhtK 3MgYTC3W3joAtdulQo9OuHLZ9m0FXQjnmQ649mhW9qLcBa8W9SlwGntAM+JfQIo= =v/bF -----END PGP SIGNATURE----- --Apple-Mail=_ED485F67-0F8D-49C1-B3FE-18D52D1DB62C-- From nobody Wed Mar 11 06:59:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40771ACCFB for ; Wed, 11 Mar 2015 06:59:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 6e7Rg8h5GIXR for ; Wed, 11 Mar 2015 06:59:54 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 D530C1A88C1 for ; Wed, 11 Mar 2015 06:59:52 -0700 (PDT) Received: by qgdz107 with SMTP id z107so10043467qgd.4 for ; Wed, 11 Mar 2015 06:59:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=O4QKO9E7H1PrmY9YvBn4nOh83KphJxq1RvhlKhSVaIE=; b=L7dCgv+GOsy40KIg0VcDlFlGSFvYIoNEaT2Sx9/ArGRaOpOZYYqzeMX8qKHnn5yhV/ fzdIr8HBQKD2LXSdktXDS9mPPz7HTt3paaaqdMmqmpe3ro7oHhJvc90jRV2MpFbX3ywb hVCGHKipIulb1UcJS912uZPXYM3Pbtxr8Spbks8jv+O3/CBVvVe+qjtuNLz3ocXO2y1z jdS4HghNPUbTMq+8utB3P/L0P/k40ru3jv5RLcj6r8SE5v5JK9AuQVCX3joGvx63sQrd BKqCXw9dhrMplUOjEQu6yIrD+zEe8lihFincYeNaRmcy+sDiK07loIGhtIvkyr9G2O61 SwpQ== X-Gm-Message-State: ALoCoQl8QBPQLlI1GeGfkI53TBE798pjIea60X0lSFPG2DL0POq6dWrk3irLDkoUc3vm5x857TBt X-Received: by 10.140.102.170 with SMTP id w39mr46185044qge.100.1426082392050; Wed, 11 Mar 2015 06:59:52 -0700 (PDT) Received: from [192.168.8.100] ([181.202.7.165]) by mx.google.com with ESMTPSA id i48sm2591475qge.34.2015.03.11.06.59.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Mar 2015 06:59:50 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_54002181-3843-4BF8-AF7B-9AA9FFD185B9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <7CDF2772-18FA-46EE-9E65-8D2740460FD1@mit.edu> Date: Wed, 11 Mar 2015 10:59:46 -0300 Message-Id: References: <7CDF2772-18FA-46EE-9E65-8D2740460FD1@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Motivation for OAuth 2.0 Dynamic Client Registration Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 13:59:57 -0000 --Apple-Mail=_54002181-3843-4BF8-AF7B-9AA9FFD185B9 Content-Type: multipart/alternative; boundary="Apple-Mail=_C1364DF9-BB72-4AEB-B93F-2EEB39E88DD1" --Apple-Mail=_C1364DF9-BB72-4AEB-B93F-2EEB39E88DD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The other thing to consider is that software statements in native apps = are only a hint from "good" clients. =20 To know for sure that it is a instance of some software you need a agent = on the device to check the signature and bundle_id, otherwise anyone = could extract the software statement and put it in some other client. The NAAPS work in the OIDF is looking at how some of that can work. John B. > On Mar 11, 2015, at 9:04 AM, Justin Richer wrote: >=20 > Hi Adam, >=20 > Yes, in fact that use case is the motivation behind allowing the = initial access token mechanism, where the developer goes and gets a = pre-registration token and passes that in through the application = itself: >=20 > https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendix-A.1.2 = >=20 > What we don=E2=80=99t specify is *how* the deployment organization = finds out about the client developer, since that=E2=80=99s so far been = something that=E2=80=99s pretty tightly tied in to deployments. In = BlueButton+ we used a combination of a structured initial access tokens = and a registry service (think of it like a trust root with discovery = components) to get this kind of information across the wire. Within your = deployment umbrella you could do something similar, or use the software = statement mechanism to carry similar information. Nobody=E2=80=99s = sought to have that specific part standardized yet, but you can = absolutely deploy it within the Dynamic Client Registration spec. >=20 > =E2=80=94 Justin >=20 >> On Mar 11, 2015, at 1:26 AM, Adam Lewis = > wrote: >>=20 >> Hi, >>=20 >> I am curious about the use cases that inspired this draft, as the = terminology that is defined within fits like a glove a use case that I = have, though the draft doesn't solve it it completely. >>=20 >> Namely the use case as I have is for the "client developer" to be = able to create a developer account with the "software API publisher" via = developer portal, and to then make their client available for download = on an app store (e.g. Google Play), where it would be downloaded by a = "deployment organization" and finally run the client registration = protocol. This fits our use case 90%, but we have a further use case = that the "software API deployment" is able to identify the "client = developer" of the application when executing in a "deployment = organization."=20 >>=20 >> I'm curious if that last part was ever identified as a use case for = the draft? >>=20 >>=20 >>=20 >> tx >> adam >> _______________________________________________ >> 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 --Apple-Mail=_C1364DF9-BB72-4AEB-B93F-2EEB39E88DD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The other thing to consider is that software statements in = native apps are only a hint from "good" clients.  
To know for sure that it is a instance = of some software you need a agent on the device to check the signature = and bundle_id,  otherwise anyone could extract the software = statement and put it in some other client.

The NAAPS work in the OIDF is looking = at how some of that can work.

John B.

On = Mar 11, 2015, at 9:04 AM, Justin Richer <jricher@MIT.EDU> = wrote:

Hi Adam,

Yes, in fact that use = case is the motivation behind allowing the initial access token = mechanism, where the developer goes and gets a pre-registration token = and passes that in through the application itself:

https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendi= x-A.1.2

What= we don=E2=80=99t specify is *how* the deployment organization finds out = about the client developer, since that=E2=80=99s so far been something = that=E2=80=99s pretty tightly tied in to deployments. In BlueButton+ we = used a combination of a structured initial access tokens and a registry = service (think of it like a trust root with discovery components) to get = this kind of information across the wire. Within your deployment = umbrella you could do something similar, or use the software statement = mechanism to carry similar information. Nobody=E2=80=99s sought to have = that specific part standardized yet, but you can absolutely deploy it = within the Dynamic Client Registration spec.

 =E2=80=94 Justin

On Mar 11, 2015, at 1:26 AM, Adam Lewis = <Adam.Lewis@motorolasolutions.com> wrote:

Hi,

I am curious about the use cases that = inspired this draft, as the terminology that is defined within fits like = a glove a use case that I have, though the draft doesn't solve it it = completely.

Namely the use case as I have is for the "client developer" = to be able to create a developer account with the "software API = publisher" via  developer portal, and to then make their client = available for download on an app store (e.g. Google Play), where it = would be downloaded by a "deployment organization" and finally run the = client registration protocol.  This fits our use case 90%, but we = have a further use case that the "software API deployment" is able to = identify the "client developer" of the application when executing in a = "deployment organization." 

I'm curious if that last part was ever = identified as a use case for the draft?



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

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

= --Apple-Mail=_C1364DF9-BB72-4AEB-B93F-2EEB39E88DD1-- --Apple-Mail=_54002181-3843-4BF8-AF7B-9AA9FFD185B9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTExMzU5NDZaMCMGCSqGSIb3DQEJBDEWBBQ1J1fwJWffDRJCcTNYsGJz QX1CYTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCi5DXM60Oi43Xxt//VDUPV5U+IdxJpj5MuzW2SU6+NJ4RDxZJ1L7Xs QXjBDjcbOEujkk+6NsFTfUOOYGaTmuJFV97plLlLSNkkeAgkBl28jxpS4LGTdCXZSaVUd6PTajdN 4Txu5Cw3s3c3y3yyxdHy1bsipMQa0ulGLEw8S/KLFHRh2IPZKQlxASW3/iATLWWBJw3eFyF9eb7j J9DUExmUJOqpvAZva5/V26kdGmAHiRsVRypsQkaVeYgaghM/ce4X6YG/rYZWfOKzSx1WO+mH+ky5 j8NMbwwZOUTSEmdEEeI1cvYCuBv7abHJ7wXGXlU8ZMd1o67LcY+ncZ0yMv+IAAAAAAAA --Apple-Mail=_54002181-3843-4BF8-AF7B-9AA9FFD185B9-- From nobody Wed Mar 11 07:18:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261661ACDCC for ; Wed, 11 Mar 2015 07:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2eh2VvWawrqG for ; Wed, 11 Mar 2015 07:18:40 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6869F1ACDCB for ; Wed, 11 Mar 2015 07:18:40 -0700 (PDT) X-AuditID: 1209190d-f792d6d000001fc7-44-55004ebe98e1 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id F0.F8.08135.EBE40055; Wed, 11 Mar 2015 10:18:38 -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 t2BEIbf7002407; Wed, 11 Mar 2015 10:18:38 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BEHgEv001753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 10:18:36 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D777F494-D79A-41A5-BFA9-ED8B50C279FE"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Justin Richer In-Reply-To: Date: Wed, 11 Mar 2015 10:18:35 -0400 Message-Id: <75F490CD-2770-4E98-A198-32329ABC5339@mit.edu> References: <7CDF2772-18FA-46EE-9E65-8D2740460FD1@mit.edu> To: John Bradley X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPKsWRmVeSWpSXmKPExsUixCmqrbvPjyHUoH2FicXObT9ZLU6+fcVm sfruXzYHZo8lS34yeUyY+IPF4/btjSwBzFFcNimpOZllqUX6dglcGR+3TGUqmB5cManpHXsD Y7tHFyMnh4SAicSjd+eYIGwxiQv31rN1MXJxCAksZpLoa5vPDpIQEtjIKLHxayhE4iGTxPJp BxlBEsICoRIrTpwHs3kFDCTmnvrCBFLELDCJUeL35J2MEGOlJB7cXgNmswmoSkxf0wK2jlPA TuJw81FmEJsFKD6naQFYDbNAmsSztlvMEEOtJFovbGaGu6KzjQ/EFhFQkdi37xFQPQfQfHmJ nk3pExgFZyE5YxayM2aBjU2S+DvlKguErS2xbOFrZghbU2J/93Is4hoSnd8mskLY8hLb386B iltKLJ55A6reVuJW3wImCNtO4tG0RawLGLlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrp5WaW 6KWmlG5iBMelJO8OxncHlQ4xCnAwKvHwOsz4HyLEmlhWXJl7iFGSg0lJlJfZlSFUiC8pP6Uy I7E4I76oNCe1+BCjCtCuRxtWX2CUYsnLz0tVEuEV9wGq401JrKxKLcqHKZPmYFES5930gy9E SCA9sSQ1OzW1ILUIJivDwaEkwbscpFGwKDU9tSItM6cEIc3EwXmIUYKDB2j4TbDhxQWJucWZ 6RD5U4yKUuK870ASAiCJjNI8uF5YOn3FKA70ljCvuy9QFQ8wFcN1vwIazAQ0mMUa6GHe4pJE hJRUA6P0e50MRffM2GCNSa4VbMdVTuQcSgretFOxyLfgrVfoviqlY8o7lxg77pomyHCqs10v YeEtxflbaiuaPjY/2VJz5uWx5El33TcVPt9kk/9TLEeYRXptdWrQ1WhLn9w1N8/+Z8vddlB7 79u6wzULfpc+Mv7Rc7rNa5uGGtshm+M3Vuv9LRD+ck2JpTgj0VCLuag4EQCBukjJggMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Motivation for OAuth 2.0 Dynamic Client Registration Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:18:43 -0000 --Apple-Mail=_D777F494-D79A-41A5-BFA9-ED8B50C279FE Content-Type: multipart/alternative; boundary="Apple-Mail=_D1502D8F-6D36-434A-8A26-40A98FC1D105" --Apple-Mail=_D1502D8F-6D36-434A-8A26-40A98FC1D105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Right, everything from a client needs to be taken with a grain of salt, = it=E2=80=99s the nature of the protocol. =E2=80=94 Justin > On Mar 11, 2015, at 9:59 AM, John Bradley wrote: >=20 > The other thing to consider is that software statements in native apps = are only a hint from "good" clients. >=20 > To know for sure that it is a instance of some software you need a = agent on the device to check the signature and bundle_id, otherwise = anyone could extract the software statement and put it in some other = client. >=20 > The NAAPS work in the OIDF is looking at how some of that can work. >=20 > John B. >=20 >> On Mar 11, 2015, at 9:04 AM, Justin Richer > wrote: >>=20 >> Hi Adam, >>=20 >> Yes, in fact that use case is the motivation behind allowing the = initial access token mechanism, where the developer goes and gets a = pre-registration token and passes that in through the application = itself: >>=20 >> = https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendix-A.1.2 = >>=20 >> What we don=E2=80=99t specify is *how* the deployment organization = finds out about the client developer, since that=E2=80=99s so far been = something that=E2=80=99s pretty tightly tied in to deployments. In = BlueButton+ we used a combination of a structured initial access tokens = and a registry service (think of it like a trust root with discovery = components) to get this kind of information across the wire. Within your = deployment umbrella you could do something similar, or use the software = statement mechanism to carry similar information. Nobody=E2=80=99s = sought to have that specific part standardized yet, but you can = absolutely deploy it within the Dynamic Client Registration spec. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 11, 2015, at 1:26 AM, Adam Lewis = > wrote: >>>=20 >>> Hi, >>>=20 >>> I am curious about the use cases that inspired this draft, as the = terminology that is defined within fits like a glove a use case that I = have, though the draft doesn't solve it it completely. >>>=20 >>> Namely the use case as I have is for the "client developer" to be = able to create a developer account with the "software API publisher" via = developer portal, and to then make their client available for download = on an app store (e.g. Google Play), where it would be downloaded by a = "deployment organization" and finally run the client registration = protocol. This fits our use case 90%, but we have a further use case = that the "software API deployment" is able to identify the "client = developer" of the application when executing in a "deployment = organization." >>>=20 >>> I'm curious if that last part was ever identified as a use case for = the draft? >>>=20 >>>=20 >>>=20 >>> tx >>> adam >>> _______________________________________________ >>> 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 --Apple-Mail=_D1502D8F-6D36-434A-8A26-40A98FC1D105 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Right, everything from a client needs to be taken with a = grain of salt, it=E2=80=99s the nature of the protocol. 

 =E2=80=94 = Justin

On Mar 11, 2015, at 9:59 AM, John Bradley = <ve7jtb@ve7jtb.com> wrote:

The other = thing to consider is that software statements in native apps are only a = hint from "good" clients.  

To know for sure that it is a instance of some software you = need a agent on the device to check the signature and bundle_id, =  otherwise anyone could extract the software statement and put it = in some other client.

The NAAPS work in the OIDF is looking at how some of that can = work.

John = B.

On Mar 11, 2015, at 9:04 AM, = Justin Richer <jricher@MIT.EDU> wrote:

Hi Adam,

Yes, in fact that use = case is the motivation behind allowing the initial access token = mechanism, where the developer goes and gets a pre-registration token = and passes that in through the application itself:

https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendi= x-A.1.2

What= we don=E2=80=99t specify is *how* the deployment organization finds out = about the client developer, since that=E2=80=99s so far been something = that=E2=80=99s pretty tightly tied in to deployments. In BlueButton+ we = used a combination of a structured initial access tokens and a registry = service (think of it like a trust root with discovery components) to get = this kind of information across the wire. Within your deployment = umbrella you could do something similar, or use the software statement = mechanism to carry similar information. Nobody=E2=80=99s sought to have = that specific part standardized yet, but you can absolutely deploy it = within the Dynamic Client Registration spec.

 =E2=80=94 Justin

On Mar 11, 2015, at 1:26 AM, Adam Lewis = <Adam.Lewis@motorolasolutions.com> wrote:

Hi,

I am curious about the use cases that = inspired this draft, as the terminology that is defined within fits like = a glove a use case that I have, though the draft doesn't solve it it = completely.

Namely the use case as I have is for the "client developer" = to be able to create a developer account with the "software API = publisher" via  developer portal, and to then make their client = available for download on an app store (e.g. Google Play), where it = would be downloaded by a "deployment organization" and finally run the = client registration protocol.  This fits our use case 90%, but we = have a further use case that the "software API deployment" is able to = identify the "client developer" of the application when executing in a = "deployment organization." 

I'm curious if that last part was ever = identified as a use case for the draft?



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

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


= --Apple-Mail=_D1502D8F-6D36-434A-8A26-40A98FC1D105-- --Apple-Mail=_D777F494-D79A-41A5-BFA9-ED8B50C279FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJVAE67AAoJEDPAngkbd+w9pLEH/j4+72NN7T1SyJXdCxybmDFb egtXvD47pnutLfkE6pJzygNaxG0+0s3oMTXXOzSlFNgWmcG1QEHzjBBtnUxPYYlR VZhCiTmJeM53IJB5t4+PBkdePm0uoOg06/PzWf4JMqdWa446H2qoJ1MvIbXABTpl RIV0WOnWU4OBfwc6YNGPYaiGX1Y7wtE5/HMf/iJn2P1WhCl3Oq2zludAh6u5qIyx qEZ5j79OqBO9iVbBXl/Xfj8aKX/M9vcNAhtaE+wy2aV20KjPpatey342IMjk67uI AyhOND2FWYAGYWjpf8GfslmovD58p2yo8smreLfEczdmps478MAMqtOZixDaVzs= =Y44q -----END PGP SIGNATURE----- --Apple-Mail=_D777F494-D79A-41A5-BFA9-ED8B50C279FE-- From nobody Wed Mar 11 07:48:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8677D1A007D for ; Tue, 10 Mar 2015 11:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 r-NZ5GfamfDc for ; Tue, 10 Mar 2015 11:33:57 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 0A2291A87B1 for ; Tue, 10 Mar 2015 11:33:57 -0700 (PDT) Received: by qgef51 with SMTP id f51so4248689qge.0 for ; Tue, 10 Mar 2015 11:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oYsH6WWaMo3hTIUO++ELM6MjM6mdsaRMRsWJYXP4s0Q=; b=ViH7pcpKTyytQab4+GnqsuGA1Vcrf4UhjaOkPLv1OyWxnO5OHo7zhAMB+P1I+p6d6W 6vF3QGNIopT7UgEpr7l4qW9N22nRn8JlKPCBBoRcc2pSwBXMqL48XHfZajTNXVlNixWF Z1vLVqRdgPvWmwdDc27H+f1eTmFcMK7scfOEv2SPimZ+dM+YTXuWU5MEdfPF/tMMCp7z szkh8SJq6yNH3rKFAAJNiOYEHnQTaOOqgPYLCKy+C0+HJ/vxp1kWpbiM8aMbf/fG1zAE 2YLvSc5WgnuU7zt7ExJ3XlPy3JsQr7Pd4wPFfBhLUlH9WjVSluuIhASNBFvr9bik73so 6k5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oYsH6WWaMo3hTIUO++ELM6MjM6mdsaRMRsWJYXP4s0Q=; b=Tb+3bV4HhF2yY9aQxy7WsN1ZO/m4D55NqlfPDBO/iodzeW+/6y2fi7IN97/fjV1Q5c mPc/A3wedIMgC/lb0GQ0TFMBFJjFFlIRSihSkhkTqVmbvuHWiVR2l/P6ARzo7Uup7W1I +ltVi+Ryn9btEn1ZbIMSzEhpcS4cCN2D0pKKqdI5TwM5+cjTk8fn64CtB2dYSCV/wRi/ N1LjFOOrKfVSrbjrIbh0az/xiREJk1EP6G5yoqz/G5YAch0173nhky2i8ukL2hwVEDFl +yfyS3gwjYCsyCtPnKCH5Ge8J+KVGtcDLPHNWnxwbEu5r0RuwYL4xOXMXrhq2rMsUig6 wsTA== X-Gm-Message-State: ALoCoQkj4uagmswNNFUxNX0J4t/sZKQO+8jDs44G6u8LCNaB81GRwLI95TDT8L8r+kSfORchYkAR X-Received: by 10.141.28.78 with SMTP id f75mr44946155qhe.18.1426012436185; Tue, 10 Mar 2015 11:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.30.3 with HTTP; Tue, 10 Mar 2015 11:33:36 -0700 (PDT) In-Reply-To: <54E372C1.8040204@gmx.net> References: <54E372C1.8040204@gmx.net> From: Naveen Agarwal Date: Tue, 10 Mar 2015 11:33:36 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11423d98b470a20510f36405 Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 07:48:18 -0700 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:33:58 -0000 --001a11423d98b470a20510f36405 Content-Type: text/plain; charset=UTF-8 > I definitely need the IPR confirmation. I'm not aware of any IPR related tho this draft. On Tue, Feb 17, 2015 at 8:56 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Nat, John, Naveen, > > thanks a lot for your work on the document. > > I still need responses to this mail to complete the shepherd writeup: > http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html > > I definitely need the IPR confirmation. > > It would also be helpful to have someone who implemented the > specification as it currently is. I asked Brian and Thorsten for > clarification regarding their statements that they implemented earlier > versions of the spec. > > As a final remark I still believe that the text regarding the randomness > is still a bit inconsistent. Here are two examples: > > 1) In the Security Consideration you write that "The security model > relies on the fact that the code verifier is not learned or guessed by > the attacker. It is vitally important to adhere to this principle. " > > 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD have > enough entropy to make it impractical to guess the value. It is > RECOMMENDED that the output of a suitable random number generator be > used to create a 32-octet sequence." > > There is clearly a long way from a SHOULD have enough entropy to the > text in the security consideration section where you ask for 32 bytes > entropy. > > It is also not clear why you ask for 32 bytes of entropy in particular. > > Ciao > Hannes > > --001a11423d98b470a20510f36405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I definitely need the IPR confirmatio= n.


I'm not aware of any IPR relat= ed tho this draft.


On Tue, Feb 17, 2015 at 8:56 AM= , Hannes Tschofenig <hannes.tschofenig@gmx.net> wrot= e:
Hi Nat, John, Naveen,

thanks a lot for your work on the document.

I still need responses to this mail to complete the shepherd writeup:
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 4100.html

I definitely need the IPR confirmation.

It would also be helpful to have someone who implemented the
specification as it currently is. I asked Brian and Thorsten for
clarification regarding their statements that they implemented earlier
versions of the spec.

As a final remark I still believe that the text regarding the randomness is still a bit inconsistent. Here are two examples:

1) In the Security Consideration you write that "The security model relies on the fact that the code verifier is not learned or guessed by
the attacker.=C2=A0 It is vitally important to adhere to this principle. &q= uot;

2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD hav= e
enough entropy to make it impractical to guess the value.=C2=A0 It is
RECOMMENDED that the output of a suitable random number generator be
used to create a 32-octet sequence."

There is clearly a long way from a SHOULD have enough entropy to the
text in the security consideration section where you ask for 32 bytes
entropy.

It is also not clear why you ask for 32 bytes of entropy in particular.

Ciao
Hannes


--001a11423d98b470a20510f36405-- From nobody Wed Mar 11 09:41:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA89F1A1A8A for ; Wed, 11 Mar 2015 09:41:16 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0X1MChBXYCkG for ; Wed, 11 Mar 2015 09:41:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087271A1A98 for ; Wed, 11 Mar 2015 09:41:06 -0700 (PDT) Received: from [192.168.10.133] ([208.85.208.52]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M2ckv-1ZNyyA2Jld-00sNVJ for ; Wed, 11 Mar 2015 17:41:04 +0100 Message-ID: <55007019.5030708@gmx.net> Date: Wed, 11 Mar 2015 17:40:57 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0AfPqwwt3h7HX8D0nhImllqxSvWnoab2v" X-Provags-ID: V03:K0:DmXS7e5Adn0Qv0w/Nn75cFwF7W+PyhURaQIfjxwuGpl1hLlYe5A lWK7mxOKYLboo5FHKPfIDRh9BseWAKaf4P5uFC94IEmHGU78s6iq63pAF4lUhmQbtkZZQgo rj9gSKruRadRVLzS1jO4C0wu4W/AVHLIGX0x1QXsi0f1AQzRvSDSWCRtlhpA3qBscWUBo5y 2M/vScywfd8x4lHzFIGlQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Tentative Agenda for IETF92 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:41:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0AfPqwwt3h7HX8D0nhImllqxSvWnoab2v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We have uploaded the agenda for the upcoming IETF meeting: http://www.ietf.org/proceedings/92/agenda/agenda-92-oauth Feedback appreciated. Ciao Hannes --0AfPqwwt3h7HX8D0nhImllqxSvWnoab2v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVAHAZAAoJEGhJURNOOiAtrvoH/jsM6UbwcX4lA9z+iXWVweDj 1e9INapBFSLPoX7I1Jy5RqgcwfFhsdflDMrRZJ4uBPYrHjFn2EPFFtMFKmx6ImKl 561D61N/xLMd7PJ36Su4E1DgpQuQbUVZkC1rfAd2R36BrLNCbwAEeQbCBzkWt1cl +fETd4wqZE5IDEt446BLyGIx3f0wImlUE4rWP8dNzz1vesFVzHHpicf2d3yRuGT2 loFVX6sGi3TZoK0uOZXTjxmx9WzePI7gysv40SKT5s4KIBZTMi6Eo9iz0zptEOjG OSBIxlVu75b2swbT0ZUq4wyt3I/82eoCpCpH5dsoBPsO02FjKuPJCRUqUdNu6g8= =7EVG -----END PGP SIGNATURE----- --0AfPqwwt3h7HX8D0nhImllqxSvWnoab2v-- From nobody Fri Mar 13 14:21:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECC61A879E for ; Fri, 13 Mar 2015 14:21:13 -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=unavailable 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 p3IPE_EU9pFQ for ; Fri, 13 Mar 2015 14:21:10 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (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 282011A8873 for ; Fri, 13 Mar 2015 14:21:06 -0700 (PDT) Received: by qgfh3 with SMTP id h3so29155955qgf.2 for ; Fri, 13 Mar 2015 14:21:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=DncSVLDpanxDdcLy0F8O/4bOZ32JoyGOiyEYEYpaNSM=; b=hXhO/B5OCzwi7Mf06Z5JmSL7XnDU5Eq4lbBX7+8ulcT1sCME4ovVT7fmpgkTYDyfdZ iTzEy0yBZ3uEn01BKZa+6rJ8Y4rF1v9gvNI/gHV8duOvCjJY3FyZPwMnv06VWZwu00dU tWWJz7wjZlFHjl61XkSShRRxBMCKCPAVrV+bUmf44tqwYJrcuV/x0cue2ywjtAVjq44Y U3yc3TCKV7qSaYIG08Xr49GS4L4c9MpFJqjUAo4ESNfz8Rl6FkS4F+tNzx3I4/PonqOH Vuf9u3BB+u+X2ZzbkoJ+WkPI/vFA1nqXXdDA8BM/sdbXYlSRWrDIM4LYxVGuZ+7L6KkR bozg== X-Gm-Message-State: ALoCoQln605jxQoFlrMqiMqn6YCDo7Lripd/vsXuPWigUZp6qs9yk5PRIKo7t1fhm8OOJquJQnof X-Received: by 10.229.68.136 with SMTP id v8mr61466487qci.16.1426281665342; Fri, 13 Mar 2015 14:21:05 -0700 (PDT) Received: from [192.168.8.101] ([181.202.25.120]) by mx.google.com with ESMTPSA id u194sm2197692qhd.36.2015.03.13.14.21.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Mar 2015 14:21:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A15129A1-D546-4305-AD1F-38508FBFB473"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <2E82C711-8A32-48D0-913B-EFB09865AEDF@oracle.com> Date: Fri, 13 Mar 2015 18:20:59 -0300 Message-Id: <28F9966C-0101-4EDB-8445-BC35C549BFD5@ve7jtb.com> References: <23715BE4-920C-497D-9C15-BF4CF49211E6@ve7jtb.com> <723006D8-4253-451E-BBCE-214FF9441706@ve7jtb.com> <2E82C711-8A32-48D0-913B-EFB09865AEDF@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Andrei Popov , "unbearable@ietf.org" , "" Subject: Re: [OAUTH-WG] [Unbearable] Scoping of keys on the client. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 21:21:13 -0000 --Apple-Mail=_A15129A1-D546-4305-AD1F-38508FBFB473 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I used that as an example. I know one AS that is doing that for refresh = tokens as it doesn't require any client or protocol change. =20 No the WG haven't discussed it. The POP use case for AT is focused on app/client to RS. Given that the = AS and RS may not be in the same domain using token binding to secure = the AT to the RS gets trickier. In principal if the client knows the the URI of the resource server it = could make a request to the RS and then take the public key and put it = in a JWK to push to the AS as part of the existing POP key distribution = spec.=20 The client would then get back a AT bound to that key. That limits the client to only using a single RS as tin the current spec = the key is only exchanged for code. The key could be sent with refresh tokens if we wanted to allow multiple = RS with different keys, however to do that securely you really want to = secure the refresh token, to do that in a public client the AS could use = token binding. Those are issues the OAuth WG will need to look at. To do that = properly knowing things like if the RT leaks to another app on the = device can it still be used? Those questions need to be answered to = formulate security considerations, and determine if token binding is the = correct tool to use for a given use case. John B. > On Mar 13, 2015, at 5:22 PM, Phil Hunt wrote: >=20 > Maybe I am recalling wrongly, but I don=E2=80=99t think OAuth WG = discussed securing refresh tokens using binding (yet). The OAuth POP = use cases were focused on app-to-app access token security. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Mar 13, 2015, at 12:58 PM, John Bradley wrote: >>=20 >> I think it is important to think through how the choices may impact = how protocols can use token binding.=20 >>=20 >> The NAAPS profile of connect is a possible candidate for using token = binding but that is highly dependent on how keys are shared on the = client.=20 >>=20 >> A simple OAuth use case is using token binding to secure a refresh = token. =20 >>=20 >> How secure that is would depend on what other apps on the device may = be able to use that token if it leaked.=20 >>=20 >> Understanding how keys are shared between apps is I think important.=20= >>=20 >> John B >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Mar 13, 2015, at 2:46 PM, Phil Hunt wrote: >>>=20 >>> The problem being that this just becomes device binding and app to = app token binding still isn't possible.=20 >>>=20 >>> Do we care? >>>=20 >>> Phil >>>=20 >>>> On Mar 13, 2015, at 10:18, Andrei Popov = wrote: >>>>=20 >>>> Thanks for raising this topic John. >>>>=20 >>>>> I found some people that believe all apps sharing a common TLS = library would be able to share the same ID/key for a origin. >>>> In our prototypes so far (in Win10), the Token Binding Protocol = implementation, the Token Binding key storage APIs, and the TLS library = are three separate components. Among other things, this allows = 3-rd-party apps share Token Binding keys and achieve single sign-on = regardless of the TLS library they might be using (if they choose to do = so). >>>>=20 >>>>> The different views impact security considerations in native = environments. As an example can you pass a token from one app to = another and have it still work to the same origin, or is it a security = feature that it won't work and the token cant be stolen from a app and = re-used by a different app on the same device. >>>> I think that single sign-on between apps and browsers is at least a = useful option. >>>>=20 >>>>> I don't think there is anything in the specs on this. >>>>> Figuring out where some of these issues get documented might be = useful. >>>> Documenting key scoping is indeed useful; on the other hand = standardizing the specifics might require standardizing user and = application isolation models across platforms, which I don't think would = be in scope for this forum. Perhaps we could agree on some general = principles and include implementation guidance on Token Binding key = scoping? >>>>=20 >>>> Cheers, >>>>=20 >>>> Andrei >>>>=20 >>>> -----Original Message----- >>>> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = John Bradley >>>> Sent: Friday, March 13, 2015 9:57 AM >>>> To: unbearable@ietf.org >>>> Subject: [Unbearable] Scoping of keys on the client. >>>>=20 >>>> Now that we are officially a WG I have a question (no hat) >>>>=20 >>>> One thing that I identified as a potential issue talking to people = who are working on early deployments, is the expectations around how = keys are shared between applications. >>>>=20 >>>> I found some people that believe all apps sharing a common TLS = library would be able to share the same ID/key for a origin. >>>>=20 >>>> Other folks were under the impression that each application would = have its own key for an origin. >>>>=20 >>>> The different views impact security considerations in native = environments. As an example can you pass a token from one app to = another and have it still work to the same origin, or is it a security = feature that it won't work and the token cant be stolen from a app and = re-used by a different app on the same device. >>>>=20 >>>> There was a middle view by the MDM people that the ID/key would be = scoped to a profile/container so that all the enterprise apps would = share ID/key but that social apps would not. >>>>=20 >>>> I don't know that there is necessarily one right answer, as this = may be implementation dependent. =20 >>>>=20 >>>> I don't think there is anything in the specs on this. One reason = I ask is that some of those differences impact on Native Application = Single Signon and OAuth. >>>>=20 >>>> In some of the Windows prototypes I understand there is a Key = Storage API that is used to share keys between the browser and apps. =20 >>>>=20 >>>> Android, Windows, iOS , OSX may all have implementation specific = details, but people building applications that leverage token binding = will need to understand the differences as they may have security and = privacy implications. >>>>=20 >>>> Figuring out where some of these issues get documented might be = useful. >>>>=20 >>>> John B. >>>>=20 >>>> _______________________________________________ >>>> Unbearable mailing list >>>> Unbearable@ietf.org >>>> https://www.ietf.org/mailman/listinfo/unbearable >=20 --Apple-Mail=_A15129A1-D546-4305-AD1F-38508FBFB473 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTMyMTIxMDBaMCMGCSqGSIb3DQEJBDEWBBROO9+nWEwxRiiCf3rUuYBC GL29JjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBhZ2YaDJrWF/ZMQwBp+0+QnAQt8iB7jsvwcY88/yh3zXq7QkRXyfUi 0XTQ2tPJ63IEPUWrNyTjBTdfatfeLGzkVHf5tOWQXl/1QH7QIhiGDp9mDEmE1s95FNDxYuEHnZPh +2qawrlcM/3fvlhPW8Bi7sExL9dzdUbA6PKuTQLlDKidVjHZiXHalMGjjhCSffquidAu+pqkSdna 7tnxgDV9W3a354On38qrfaUGiyMoGDOWzxyahc1sJhk0qYRhvbn0UuiezOLHTCQTup/cPS2nnOnm mwF6hpAaydYstXHjXY9s7Ub8XLotJ7uFMIF4A8d6MEPKuMxb6rmcewNU+8/LAAAAAAAA --Apple-Mail=_A15129A1-D546-4305-AD1F-38508FBFB473-- From nobody Sun Mar 15 10:18:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086D81A1B51 for ; Sun, 15 Mar 2015 10:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 XI3Jx0n0Qgav for ; Sun, 15 Mar 2015 10:18:19 -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 D23E01A0358 for ; Sun, 15 Mar 2015 10:18:18 -0700 (PDT) Received: from [79.253.34.96] (helo=[192.168.71.100]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YXCB6-0003kk-3T; Sun, 15 Mar 2015 18:18:16 +0100 Message-ID: <5505BED5.50307@lodderstedt.net> Date: Sun, 15 Mar 2015 18:18:13 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Josh Mandel , "oauth@ietf.org WG" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000404010203040306060103" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 17:18:22 -0000 This is a multi-part message in MIME format. --------------000404010203040306060103 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Josh, I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2). Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic. kind regards, Torsten. Am 03.03.2015 um 18:27 schrieb Josh Mandel: > Hi All, > > In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit > Resource Server"), RFC6819 describes a threat where a counterfeit > resource server tricks a client into obtaining and sharing an access > token from a legitimate authorization server. One of the proposed > mitigations involves: "telling the authorization server about the > resource server endpoint URL in the authorization process." > > In other words, this mitigation would ask the client to pass an > additional parameter when redirecting to the Authorization server's > "authorize" URL, effectively something like: > > https://auth-server/authorize? > response_type=code& > client_id=123& > state=456& > scope=read-all& > redirect_uri=https://app-server/after-auth& > *resource_server_that_told_me_to_authorize_here=https://attacker.com* > * > * > (And if the authorization server saw a value it didn't like in the > final parameter, it would reject the request.) > > This is obviously not appropriate in every authorization scenario, but > it is useful anytime there's a discovery process by which apps learn > about authorization servers from resource servers. Since it's > something of a common need, I wanted to see if there was any common > practice in how to name this parameter, or whether it's worth > registering a standard extension at > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . > (I don't see one there now -- possibly I'm just missing it.) > > If so, what should it be called? The name I used in the example above > is a bit verbose :-) > > Best, > > Josh > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000404010203040306060103 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

response_type=code&
client_id=123&
state=456&
scope=read-all&
resource_server_that_told_me_to_authorize_here=https://attacker.com

(And if the authorization server saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The name I used in the example above is a bit verbose :-)

Best,

  Josh


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

--------------000404010203040306060103-- From nobody Sun Mar 15 10:34:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F911A1B5B for ; Sun, 15 Mar 2015 10:34:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ZQUAEHFr1pbW for ; Sun, 15 Mar 2015 10:34:47 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (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 02B9D1A0018 for ; Sun, 15 Mar 2015 10:34:46 -0700 (PDT) Received: by qgez64 with SMTP id z64so23560743qge.2 for ; Sun, 15 Mar 2015 10:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0xDGBQo0qzlKqLD2rqTX8NPrNYlyM2rpxLQbN77BVU4=; b=VtEHJp5nMw9wmhnme0olgT9VQ4wgepME+VPg5Ok7SZg3V3P33CDD1n+FmaKwShFghf kXElAAuuIU/4DBaaVu0P1iyU9J7jhrYIHchO6YuuD7qx/7AZ8UsoD7St+Ya1gMdVEGvZ 4umt7UCqaCRfUCsJc+Zv+0lU7RModu6f+pcuXGH9Gtjz8Evy2NuX+KMCW7qKGXo8n+ek lF5eSS/5a9YdLOW6SvDqxDTt2pWwmT95Xuu1cXp0Ns22+NqshpYM4axdkhJSOR1LQCGC 0QRoWBD6sweCVHlY6xCLpb7W6a8ol/jCamiIuF4yKQ/E2dPKCaRw+vhkBaHxVT6KXZvc ikug== X-Gm-Message-State: ALoCoQnPtUq2RNC9bgDOT/JLu8nsJHAvWM8WMJD0530B0aAQVeyZlP9NZXenc10uptNhdYprO/H5 X-Received: by 10.55.51.77 with SMTP id z74mr43947600qkz.84.1426440886194; Sun, 15 Mar 2015 10:34:46 -0700 (PDT) Received: from [192.168.8.101] ([181.202.26.213]) by mx.google.com with ESMTPSA id 9sm5818602qgo.38.2015.03.15.10.34.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Mar 2015 10:34:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_25E9AD5F-6895-4439-A931-20A99284BED7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <5505BED5.50307@lodderstedt.net> Date: Sun, 15 Mar 2015 14:34:40 -0300 Message-Id: <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> References: <5505BED5.50307@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Dixie Baker , "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 17:34:49 -0000 --Apple-Mail=_25E9AD5F-6895-4439-A931-20A99284BED7 Content-Type: multipart/alternative; boundary="Apple-Mail=_D49307AF-C904-4906-B681-127760E91ABA" --Apple-Mail=_D49307AF-C904-4906-B681-127760E91ABA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In POP key distribution we do introduce a "audiance" parameter to the = token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = It would be possible to have a small spec to define using "aud" with = bearer tokens, however that would be undefined behaviour at this point. I don't know of any clients that would try to access a RS server and = then besed on the error response try and get a access token from the AS = specified in the error. In POP we are trying to both protect agains that attack and more common = ones like doing a MiM to intercept the AT or the RS being hacked and = leaking the token. Using "aud" with bearer tokens would be useful, but probably won't stop = the majority of possible AT leaks. John B. > On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = wrote: >=20 > Hi Josh, >=20 > I'm not aware of a common practice to use such a parameter. The WG is = instead heading towards authenticated requests to the resource server = (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >=20 > Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >=20 > kind regards, > Torsten. >=20 > Am 03.03.2015 um 18:27 schrieb Josh Mandel: >> Hi All, >>=20 >> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>=20 >> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>=20 >> https://auth-server/authorize ? >> response_type=3Dcode& >> client_id=3D123& >> state=3D456& >> scope=3Dread-all& >> redirect_uri=3Dhttps://app-server/after-auth& = >> resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>=20 >> (And if the authorization server saw a value it didn't like in the = final parameter, it would reject the request.) >>=20 >> This is obviously not appropriate in every authorization scenario, = but it is useful anytime there's a discovery process by which apps learn = about authorization servers from resource servers. Since it's something = of a common need, I wanted to see if there was any common practice in = how to name this parameter, or whether it's worth registering a standard = extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>=20 >> If so, what should it be called? The name I used in the example above = is a bit verbose :-) >>=20 >> Best, >>=20 >> Josh >>=20 >>=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 --Apple-Mail=_D49307AF-C904-4906-B681-127760E91ABA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 In POP key distribution we do introduce a "audiance" = parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-01#section-3.1

It would be possible to have a small spec to define using = "aud" with bearer tokens, however that would be undefined behaviour at = this point.

I = don't know of any clients that would try to access a RS server and then = besed on the error response try and get a access token from the AS = specified in the error.

In POP we are trying to both protect agains that attack and = more common ones like doing a MiM to intercept the AT or the RS being = hacked and leaking the token.

Using "aud" with bearer tokens would be = useful, but probably won't stop the majority of possible AT = leaks.

John = B.


On = Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.i= etf.org/html/rfc6819#section-5.4.2).

Please take a look onto http= ://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing = by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the = client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it = didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every = authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-paramete= rs.xhtml . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? The name I used = in the example above is a bit verbose :-)

Best,

  Josh


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

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

= --Apple-Mail=_D49307AF-C904-4906-B681-127760E91ABA-- --Apple-Mail=_25E9AD5F-6895-4439-A931-20A99284BED7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTUxNzM0NDBaMCMGCSqGSIb3DQEJBDEWBBSAUEG3h5rPV86qwFltNHf5 /ZdKCDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCyzL2RykGPzsMF+fTA8Xrtd8jjskMMjEJz1BbKrIvS2jXCvFl58dPs x0qX0TNu/vnfGhsjG8i97USs7Ya4CFw5Vo5AfNHQGABYy4mGlL3qtsaEQiULCDzdGOsVEdZ/fNV5 0n7lXr7BbyUkc9VfWv1nv8oEpU3Hp34yH1YL4pUDQVM26hQWULxSdSlobLbYdzG/Lmb29KPT0Na5 R2/s3zbOeG3Dl8T9Ce2s2/KrrrI8CjS6zGXwUtsWMGdcnqjLAKDUwRCxsD/02Rdqsyh4Fz8o9joo pC9uvIbWM4+KxgBd4xt819EIB7NbgnhzzbikQA+V61cKxcBsIvRwDBzRPwm1AAAAAAAA --Apple-Mail=_25E9AD5F-6895-4439-A931-20A99284BED7-- From nobody Mon Mar 16 06:44:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915C31A8768 for ; Mon, 16 Mar 2015 06:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 t7CbANQvmu26 for ; Mon, 16 Mar 2015 06:44:27 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DB01A8756 for ; Mon, 16 Mar 2015 06:44:13 -0700 (PDT) Received: from mail-ig0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKVQbeLbZA10l64I+eJI0tOY8/txprfzmH@postini.com; Mon, 16 Mar 2015 06:44:13 PDT Received: by igbue6 with SMTP id ue6so41844974igb.1 for ; Mon, 16 Mar 2015 06:44:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=S+nGUyC9H0aPhFHmo7K6Kn5ckwI+yZv/Ky7Fo9mMNOg=; b=D/YVEIXe0HeHPehDwOuK/DxDHMjhoAsQhqejtKOHIZ9FIPQQL7iQLWZxZx1tJgulaQ tWLgAOslb52sjvXa6vki2XDl5YEve5qXy+9nWIbr5Dh6xspPO5nraXCEbGprqQ9qM1jb nZcVVAlodTLvvKUSOaI90UmT9IZNcY35Y/mEQydpyk1909ajC6OP1cJ4xIeTHwsEGG/L 4k8cZJVmjRVsCsTyGxs3OKf8TBVx4GTvusLMPfYpnOUPr4Gl0pGO1mURGs6JTP21Y/Z6 vVItrwm44wX5O1jMcNSfJ+1r/8sAZ6qfU4vWgeIZZahHgxhL/pQy5iFtyy20GcEnw8bI KqkA== X-Gm-Message-State: ALoCoQkggbyv3xETe2I+uFEe9KGRj4eDxlsnanCfn6tY0YBibvX01jMRumsede76fyvOjsKw90h8omvdtIjxEqCxLCqy7xN2/r8aqBPxXlYlbYpXKKJcPSaQwelJCegcUDByBXfgp4LI X-Received: by 10.42.27.80 with SMTP id i16mr80543411icc.9.1426513452717; Mon, 16 Mar 2015 06:44:12 -0700 (PDT) X-Received: by 10.42.27.80 with SMTP id i16mr80543381icc.9.1426513452510; Mon, 16 Mar 2015 06:44:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.143.138 with HTTP; Mon, 16 Mar 2015 06:43:42 -0700 (PDT) In-Reply-To: <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> From: Brian Campbell Date: Mon, 16 Mar 2015 07:43:42 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=20cf3043529e9ac8f70511680b47 Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:44:29 -0000 --20cf3043529e9ac8f70511680b47 Content-Type: text/plain; charset=UTF-8 We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identify the RS to whom the AT should be issued. It is useful but it's mostly about getting format/content/etc of the AT correct for the RS rather than it is about preventing possible AT leaks. I do think an "aud(iance)" parameter at both token and authorization endpoints would have utility beyond the POP work. So defining it independently might make sense. On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: > In POP key distribution we do introduce a "audiance" parameter to the > token_endpoint. > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1 > > It would be possible to have a small spec to define using "aud" with > bearer tokens, however that would be undefined behaviour at this point. > > I don't know of any clients that would try to access a RS server and then > besed on the error response try and get a access token from the AS > specified in the error. > > In POP we are trying to both protect agains that attack and more common > ones like doing a MiM to intercept the AT or the RS being hacked and > leaking the token. > > Using "aud" with bearer tokens would be useful, but probably won't stop > the majority of possible AT leaks. > > John B. > > > On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt > wrote: > > Hi Josh, > > I'm not aware of a common practice to use such a parameter. The WG is > instead heading towards authenticated requests to the resource server (see > https://tools.ietf.org/html/rfc6819#section-5.4.2). > > Please take a look onto > http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further > drafts on this topic. > > kind regards, > Torsten. > > Am 03.03.2015 um 18:27 schrieb Josh Mandel: > > Hi All, > > In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource > Server"), RFC6819 describes a threat where a counterfeit resource server > tricks a client into obtaining and sharing an access token from a > legitimate authorization server. One of the proposed mitigations involves: > "telling the authorization server about the resource server endpoint URL in > the authorization process." > > In other words, this mitigation would ask the client to pass an > additional parameter when redirecting to the Authorization server's > "authorize" URL, effectively something like: > > https://auth-server/authorize? > response_type=code& > client_id=123& > state=456& > scope=read-all& > redirect_uri=https://app-server/after-auth& > *resource_server_that_told_me_to_authorize_here=https://attacker.com > * > > (And if the authorization server saw a value it didn't like in the final > parameter, it would reject the request.) > > This is obviously not appropriate in every authorization scenario, but > it is useful anytime there's a discovery process by which apps learn about > authorization servers from resource servers. Since it's something of a > common need, I wanted to see if there was any common practice in how to > name this parameter, or whether it's worth registering a standard extension > at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml > . (I don't see one there now -- possibly I'm just missing it.) > > If so, what should it be called? The name I used in the example above is > a bit verbose :-) > > Best, > > Josh > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://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 > > --20cf3043529e9ac8f70511680b47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've used "aud" (optionally) with OAut= h 2 and bearer tokens to help identify the RS to whom the AT should be issu= ed. It is useful but it's mostly about getting format/content/etc of th= e AT correct for the RS rather than it is about preventing possible AT leak= s.

I do think an "aud(iance)" parameter at both toke= n and authorization endpoints would have utility beyond the POP work. So de= fining it independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, John B= radley <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do i= ntroduce a "audiance" parameter to the token_endpoint.=C2=A0https://tools.ietf.org/html/draft-ietf-oauth= -pop-key-distribution-01#section-3.1

It would be pos= sible to have a small spec to define using "aud" with bearer toke= ns, however that would be undefined behaviour at this point.

=
I don't know of any clients that would try to access a RS se= rver and then besed on the error response try and get a access token from t= he AS specified in the error.

In POP we are trying= to both protect agains that attack and more common ones like doing a MiM t= o intercept the AT or the RS being hacked and leaking the token.
=
Using "aud" with bearer tokens would be useful, bu= t probably won't stop the majority of possible AT leaks.

=
John B.


On Mar 15, 2015, at 2:18 PM, Torsten Lodder= stedt <tors= ten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2)= .

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-archite= cture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resour= ce server endpoint URL in the authorization process."

In other words, this mitigation would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively= something like:

response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it didn't lik= e in the final parameter, it would reject the request.)

This is obviously not appropriate in every authorization scenario, but it is useful anytime there's a discovery proces= s by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at=C2=A0http://www.iana.org/= assignments/oauth-parameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing= it.)

If so, what should it be called? The name I used in the example above is a bit verbose :-)

Best,

=C2=A0 Josh


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

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


--20cf3043529e9ac8f70511680b47-- From nobody Mon Mar 16 10:40:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EEE1A891E for ; Mon, 16 Mar 2015 10:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lignP5QcXtqp for ; Mon, 16 Mar 2015 10:40:43 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) (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 C75821A891A for ; Mon, 16 Mar 2015 10:40:42 -0700 (PDT) Received: from [80.187.108.215] (helo=[10.132.205.232]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1YXZ0J-0003t6-3m; Mon, 16 Mar 2015 18:40:39 +0100 References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> Mime-Version: 1.0 (1.0) In-Reply-To: <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4AB5A503-1AF1-4093-B814-69E36F946F5C Content-Transfer-Encoding: 7bit Message-Id: <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> X-Mailer: iPad Mail (12D508) From: Torsten Lodderstedt Date: Mon, 16 Mar 2015 18:40:04 +0100 To: Dixie Baker X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:40:47 -0000 --Apple-Mail-4AB5A503-1AF1-4093-B814-69E36F946F5C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I don't think putting an aud into an AT will help to prevent counterfeit RSs= (as long as the aud is nit directly derived from the original URL used by t= he client to invoke the counterfeit RS. as long as the aud is a symbolic nam= e of any kind, the counterfeit RS will accept ATs for the legitimate RS and j= ust (ab)use it. POP on the contrary helps since the counterfeit RS, in order to send a messa= ge to the legitimate RS, needs to produce a new digitally signed message usi= ng the correct secret, which it doesn't know. kind regards, Torsten. > Am 16.03.2015 um 17:40 schrieb Dixie Baker = : >=20 > Using the "aud" parameter makes sense to me. Good suggestion. >=20 > Authenticating the client to the RS would not address the counterfeit RS t= hreat.=20 >=20 > -Dixie >=20 > =20 > Dixie B. Baker, Ph.D. > Senior Partner > Martin, Blanck and Associates > Office (Redondo Beach, CA): 310-791-9671 > Mobile: 310-279-2579 >=20 >> On Mar 16, 2015, at 6:43 AM, Brian Campbell w= rote: >>=20 >> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help iden= tify the RS to whom the AT should be issued. It is useful but it's mostly ab= out getting format/content/etc of the AT correct for the RS rather than it i= s about preventing possible AT leaks. >>=20 >> I do think an "aud(iance)" parameter at both token and authorization endp= oints would have utility beyond the POP work. So defining it independently m= ight make sense.=20 >>=20 >>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote= : >>> In POP key distribution we do introduce a "audiance" parameter to the to= ken_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribut= ion-01#section-3.1 >>>=20 >>> It would be possible to have a small spec to define using "aud" with bea= rer tokens, however that would be undefined behaviour at this point. >>>=20 >>> I don't know of any clients that would try to access a RS server and the= n besed on the error response try and get a access token from the AS specifi= ed in the error. >>>=20 >>> In POP we are trying to both protect agains that attack and more common o= nes like doing a MiM to intercept the AT or the RS being hacked and leaking t= he token. >>>=20 >>> Using "aud" with bearer tokens would be useful, but probably won't stop t= he majority of possible AT leaks. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt wrote: >>>>=20 >>>> Hi Josh, >>>>=20 >>>> I'm not aware of a common practice to use such a parameter. The WG is i= nstead heading towards authenticated requests to the resource server (see ht= tps://tools.ietf.org/html/rfc6819#section-5.4.2).=20 >>>>=20 >>>> Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop= -architecture and further drafts on this topic. >>>>=20 >>>> kind regards, >>>> Torsten. >>>>=20 >>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>> Hi All, >>>>>=20 >>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resour= ce Server"), RFC6819 describes a threat where a counterfeit resource server t= ricks a client into obtaining and sharing an access token from a legitimate a= uthorization server. One of the proposed mitigations involves: "telling the a= uthorization server about the resource server endpoint URL in the authorizat= ion process." >>>>>=20 >>>>> In other words, this mitigation would ask the client to pass an additi= onal parameter when redirecting to the Authorization server's "authorize" UR= L, effectively something like: >>>>>=20 >>>>> https://auth-server/authorize? >>>>> response_type=3Dcode& >>>>> client_id=3D123& >>>>> state=3D456& >>>>> scope=3Dread-all& >>>>> redirect_uri=3Dhttps://app-server/after-auth& >>>>> resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com >>>>>=20 >>>>> (And if the authorization server saw a value it didn't like in the fin= al parameter, it would reject the request.) >>>>>=20 >>>>> This is obviously not appropriate in every authorization scenario, but= it is useful anytime there's a discovery process by which apps learn about a= uthorization servers from resource servers. Since it's something of a common= need, I wanted to see if there was any common practice in how to name this p= arameter, or whether it's worth registering a standard extension at http://w= ww.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (I don't s= ee one there now -- possibly I'm just missing it.) >>>>>=20 >>>>> If so, what should it be called? The name I used in the example above i= s a bit verbose :-) >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Josh >>>>>=20 >>>>>=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 --Apple-Mail-4AB5A503-1AF1-4093-B814-69E36F946F5C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't think putting an aud into an A= T will help to prevent counterfeit RSs (as long as the aud is nit directly d= erived from the original URL used by the client to invoke the counterfeit RS= . as long as the aud is a symbolic name of any kind, the counterfeit RS will= accept ATs for the legitimate RS and just (ab)use it.

<= div>POP on the contrary helps since the counterfeit RS, in order to send a m= essage to the legitimate RS, needs to produce a new digitally signed message= using the correct secret, which it doesn't know.

k= ind regards,
Torsten.



Am 16.03.2015 um 1= 7:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "aud" parameter makes sense to me.  Good suggestion.<= div>
Authenticating the client to the RS would not address the= counterfeit RS threat. 

-Dixie

=
 
Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates=
Office (Redondo Beach, CA):  310-791-9671
Mobile:  310-279-= 2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
We've used "aud" (optionally) with OAuth 2 and bearer tokens t= o help identify the RS to whom the AT should be issued. It is useful but it'= s mostly about getting format/content/etc of the AT correct for the RS rathe= r than it is about preventing possible AT leaks.

I do think an "= aud(iance)" parameter at both token and authorization endpoints would have u= tility beyond the POP work. So defining it independently might make sense. <= br>

On Sun, M= ar 15, 2015 at 11:34 AM, John Bradley <ve7jtb@ve7jtb.com> wrot= e:
In P= OP key distribution we do introduce a "audiance" parameter to the token_endp= oint. https://tools.ietf.org/html/dr= aft-ietf-oauth-pop-key-distribution-01#section-3.1

It= would be possible to have a small spec to define using "aud" with bearer to= kens, however that would be undefined behaviour at this point.
I don't know of any clients that would try to access a RS server= and then besed on the error response try and get a access token from the AS= specified in the error.

In POP we are trying to bo= th protect agains that attack and more common ones like doing a MiM to inter= cept the AT or the RS being hacked and leaking the token.

Using "aud" with bearer tokens would be useful, but probably won't st= op the majority of possible AT leaks.

John B.
=


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net>= wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2). <= br>
Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architect= ure and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com
=

(And if the authorization server saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/as= signments/oauth-parameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The name I used in the example above is a bit verbose :-)

Best,

  Josh


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

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


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



= --Apple-Mail-4AB5A503-1AF1-4093-B814-69E36F946F5C-- From nobody Mon Mar 16 10:48:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E901A8935 for ; Mon, 16 Mar 2015 10:48:07 -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, SPF_PASS=-0.001] autolearn=ham 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 lu1orqwG8Q9b for ; Mon, 16 Mar 2015 10:48:04 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 BC59D1A891C for ; Mon, 16 Mar 2015 10:48:03 -0700 (PDT) Received: by oier21 with SMTP id r21so44494305oie.1 for ; Mon, 16 Mar 2015 10:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PAJ/Xkb6Q0hfcc2nzIlLC/IKT8GWxcW8G+vVtLAVwsA=; b=qfZJtWKg6PtgRYJbXYoPOk3wcndWRLMa5LpGCLq0s+YYXOPlsethJHlouWU8Ev4GOm wVh9l60Jnha2R1eBLckQchpoi/ud0kIkzV6X/R23F1K1ChmPoViSPHR/IgYyd7esNwBH c3yZ3MWRssqQD1zKbRaUaS9uAXow99QCeyk7OTe9TKPXaM3fh8edY3Fxsjnn+GIJS9I0 YpwHQlt76cDJ045OQL8uLXrDMM7EtKduz94o6bG0sFLXN+tERUlVifMcb+dneGK/PJs2 KEZE5jiOWxps4XAD6X4XLj3kJpxqcMe6Ur39p58sxYoWOroP40XymwZPOFjSI015lrUg udGg== X-Received: by 10.60.65.101 with SMTP id w5mr6249689oes.38.1426528083262; Mon, 16 Mar 2015 10:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.97.102 with HTTP; Mon, 16 Mar 2015 10:47:42 -0700 (PDT) In-Reply-To: <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> From: Josh Mandel Date: Mon, 16 Mar 2015 10:47:42 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a11c1d19caa433705116b73a6 Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:48:07 -0000 --001a11c1d19caa433705116b73a6 Content-Type: text/plain; charset=ISO-8859-1 Hi Torsten, You're absolutely correct. The implementation we're contemplating for SMART Platforms does indeed derive the "aud" parameter from the actual URL that the client used to communicate with the RS. Very briefly, the flow is: 1. Electronic Health Record system tells an app to launch, passing the app its RS endpoint as an issuer (iss) URL parameter. 2. App queries the RS's issuer URL to learn what AS to talk to 3. App contacts AS's authorize endpoint, passing an "aud" param that was the same as the issuer from step 1. 4. After obtaining a token, app talks to the RS using that token. -Josh On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > I don't think putting an aud into an AT will help to prevent counterfeit > RSs (as long as the aud is nit directly derived from the original URL used > by the client to invoke the counterfeit RS. as long as the aud is a > symbolic name of any kind, the counterfeit RS will accept ATs for the > legitimate RS and just (ab)use it. > > POP on the contrary helps since the counterfeit RS, in order to send a > message to the legitimate RS, needs to produce a new digitally signed > message using the correct secret, which it doesn't know. > > kind regards, > Torsten. > > > > Am 16.03.2015 um 17:40 schrieb Dixie Baker >: > > Using the "aud" parameter makes sense to me. Good suggestion. > > Authenticating the client to the RS would not address the counterfeit RS > threat. > > -Dixie > > > Dixie B. Baker, Ph.D. > Senior Partner > Martin, Blanck and Associates > Office (Redondo Beach, CA): 310-791-9671 > Mobile: 310-279-2579 > > On Mar 16, 2015, at 6:43 AM, Brian Campbell > wrote: > > We've used "aud" (optionally) with OAuth 2 and bearer tokens to help > identify the RS to whom the AT should be issued. It is useful but it's > mostly about getting format/content/etc of the AT correct for the RS rather > than it is about preventing possible AT leaks. > > I do think an "aud(iance)" parameter at both token and authorization > endpoints would have utility beyond the POP work. So defining it > independently might make sense. > > On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: > >> In POP key distribution we do introduce a "audiance" parameter to the >> token_endpoint. >> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1 >> >> It would be possible to have a small spec to define using "aud" with >> bearer tokens, however that would be undefined behaviour at this point. >> >> I don't know of any clients that would try to access a RS server and then >> besed on the error response try and get a access token from the AS >> specified in the error. >> >> In POP we are trying to both protect agains that attack and more common >> ones like doing a MiM to intercept the AT or the RS being hacked and >> leaking the token. >> >> Using "aud" with bearer tokens would be useful, but probably won't stop >> the majority of possible AT leaks. >> >> John B. >> >> >> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt >> wrote: >> >> Hi Josh, >> >> I'm not aware of a common practice to use such a parameter. The WG is >> instead heading towards authenticated requests to the resource server (see >> https://tools.ietf.org/html/rfc6819#section-5.4.2). >> >> Please take a look onto >> http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further >> drafts on this topic. >> >> kind regards, >> Torsten. >> >> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >> >> Hi All, >> >> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit >> Resource Server"), RFC6819 describes a threat where a counterfeit resource >> server tricks a client into obtaining and sharing an access token from a >> legitimate authorization server. One of the proposed mitigations involves: >> "telling the authorization server about the resource server endpoint URL in >> the authorization process." >> >> In other words, this mitigation would ask the client to pass an >> additional parameter when redirecting to the Authorization server's >> "authorize" URL, effectively something like: >> >> https://auth-server/authorize? >> response_type=code& >> client_id=123& >> state=456& >> scope=read-all& >> redirect_uri=https://app-server/after-auth& >> *resource_server_that_told_me_to_authorize_here=https://attacker.com >> * >> >> (And if the authorization server saw a value it didn't like in the >> final parameter, it would reject the request.) >> >> This is obviously not appropriate in every authorization scenario, but >> it is useful anytime there's a discovery process by which apps learn about >> authorization servers from resource servers. Since it's something of a >> common need, I wanted to see if there was any common practice in how to >> name this parameter, or whether it's worth registering a standard extension >> at >> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml >> . (I don't see one there now -- possibly I'm just missing it.) >> >> If so, what should it be called? The name I used in the example above >> is a bit verbose :-) >> >> Best, >> >> Josh >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c1d19caa433705116b73a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Torsten,

You're absolutely corre= ct. The implementation we're contemplating for SMART Platforms does ind= eed derive the "aud" parameter from the actual URL that the clien= t used to communicate with the RS. Very briefly, the flow is:

1. Electronic Health Record system tells an app to launch, passing th= e app its RS endpoint as an issuer (iss) URL parameter.
2. App qu= eries the RS's issuer URL to learn what AS to talk to
3. App = contacts AS's authorize endpoint, passing an "aud" param that= was the same as the issuer from step 1.
4. After obtaining a tok= en, app talks to the RS using that token.

=A0 -Jos= h


On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt <t= orsten@lodderstedt.net> wrote:
I don't think putting an aud into an AT will= help to prevent counterfeit RSs (as long as the aud is nit directly derive= d from the original URL used by the client to invoke the counterfeit RS. as= long as the aud is a symbolic name of any kind, the counterfeit RS will ac= cept ATs for the legitimate RS and just (ab)use it.

POP on the contrary helps since the counterfeit RS, in order to send a me= ssage to the legitimate RS, needs to produce a new digitally signed message= using the correct secret, which it doesn't know.

<= div>kind regards,
Torsten.



Am 16.03.201= 5 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "aud" parameter make= s sense to me.=A0 Good suggestion.

Authenticating the cl= ient to the RS would not address the counterfeit RS threat.=A0
-Dixie

=A0
Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and= Associates
Office (Redondo Beach, CA): =A0310-791-9671
Mobile: =A0310-279-= 2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell = <bcampbe= ll@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 a= nd bearer tokens to help identify the RS to whom the AT should be issued. I= t is useful but it's mostly about getting format/content/etc of the AT = correct for the RS rather than it is about preventing possible AT leaks.
I do think an "aud(iance)" parameter at both token and= authorization endpoints would have utility beyond the POP work. So definin= g it independently might make sense.
<= br>
On Sun, Mar 15, 2015 at 11:34 AM, John Bradle= y <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do introd= uce a "audiance" parameter to the token_endpoint.=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-key= -distribution-01#section-3.1

It would be possible to= have a small spec to define using "aud" with bearer tokens, howe= ver that would be undefined behaviour at this point.

I don't know of any clients that would try to access a RS server and= then besed on the error response try and get a access token from the AS sp= ecified in the error.

In POP we are trying to both= protect agains that attack and more common ones like doing a MiM to interc= ept the AT or the RS being hacked and leaking the token.

Using "aud" with bearer tokens would be useful, but probab= ly won't stop the majority of possible AT leaks.

John B.


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2)= .

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-archite= cture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resour= ce server endpoint URL in the authorization process."

In other words, this mitigation would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively= something like:

response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it didn't lik= e in the final parameter, it would reject the request.)

This is obviously not appropriate in every authorization scenario, but it is useful anytime there's a discovery proces= s by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at=A0http://www.iana.org/ass= ignments/oauth-parameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing= it.)

If so, what should it be called? The name I used in the example above is a bit verbose :-)

Best,

=A0 Josh


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://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


--001a11c1d19caa433705116b73a6-- From nobody Mon Mar 16 10:59:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9831A88F2 for ; Mon, 16 Mar 2015 10:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 h9Aq8aAyC9mY for ; Mon, 16 Mar 2015 10:59:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFA41A897A for ; Mon, 16 Mar 2015 10:59:12 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2GHxAl5004009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Mar 2015 17:59:11 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2GHx9h5003559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Mar 2015 17:59:09 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2GHx9YP003910; Mon, 16 Mar 2015 17:59:09 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Mar 2015 10:59:08 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_BE7760D6-BA57-411A-AC94-53DA6EE7485C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: Date: Mon, 16 Mar 2015 10:59:07 -0700 Message-Id: References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> To: Josh Mandel X-Mailer: Apple Mail (2.2070.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Cc: Dixie Baker , "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:59:17 -0000 --Apple-Mail=_BE7760D6-BA57-411A-AC94-53DA6EE7485C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Josh, I=92m not sure this helps. It seems to me, a phishing link could tell = your app to launch and pass in any RS value could it not? Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 16, 2015, at 10:47 AM, Josh Mandel wrote: >=20 > Hi Torsten, >=20 > You're absolutely correct. The implementation we're contemplating for = SMART Platforms does indeed derive the "aud" parameter from the actual = URL that the client used to communicate with the RS. Very briefly, the = flow is: >=20 > 1. Electronic Health Record system tells an app to launch, passing the = app its RS endpoint as an issuer (iss) URL parameter. > 2. App queries the RS's issuer URL to learn what AS to talk to > 3. App contacts AS's authorize endpoint, passing an "aud" param that = was the same as the issuer from step 1. > 4. After obtaining a token, app talks to the RS using that token. >=20 > -Josh >=20 >=20 > On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt = > wrote: > I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >=20 > POP on the contrary helps since the counterfeit RS, in order to send a = message to the legitimate RS, needs to produce a new digitally signed = message using the correct secret, which it doesn't know. >=20 > kind regards, > Torsten. >=20 >=20 >=20 > Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >=20 >> Using the "aud" parameter makes sense to me. Good suggestion. >>=20 >> Authenticating the client to the RS would not address the counterfeit = RS threat.=20 >>=20 >> -Dixie >>=20 >> =20 >> Dixie B. Baker, Ph.D. >> Senior Partner >> Martin, Blanck and Associates >> Office (Redondo Beach, CA): 310-791-9671 >> Mobile: 310-279-2579 >> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>=20 >>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help = identify the RS to whom the AT should be issued. It is useful but it's = mostly about getting format/content/etc of the AT correct for the RS = rather than it is about preventing possible AT leaks. >>>=20 >>> I do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.=20 >>>=20 >>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>=20 >>> It would be possible to have a small spec to define using "aud" with = bearer tokens, however that would be undefined behaviour at this point. >>>=20 >>> I don't know of any clients that would try to access a RS server and = then besed on the error response try and get a access token from the AS = specified in the error. >>>=20 >>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>=20 >>> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>=20 >>>> Hi Josh, >>>>=20 >>>> I'm not aware of a common practice to use such a parameter. The WG = is instead heading towards authenticated requests to the resource server = (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>=20 >>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>=20 >>>> kind regards, >>>> Torsten. >>>>=20 >>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>> Hi All, >>>>>=20 >>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>=20 >>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>=20 >>>>> https://auth-server/authorize ? >>>>> response_type=3Dcode& >>>>> client_id=3D123& >>>>> state=3D456& >>>>> scope=3Dread-all& >>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>=20 >>>>> (And if the authorization server saw a value it didn't like in the = final parameter, it would reject the request.) >>>>>=20 >>>>> This is obviously not appropriate in every authorization scenario, = but it is useful anytime there's a discovery process by which apps learn = about authorization servers from resource servers. Since it's something = of a common need, I wanted to see if there was any common practice in = how to name this parameter, or whether it's worth registering a standard = extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>=20 >>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Josh >>>>>=20 >>>>>=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 > _______________________________________________ > 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=_BE7760D6-BA57-411A-AC94-53DA6EE7485C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Josh,

I=92m not sure this helps. It seems to = me, a phishing link could tell your app to launch and pass in any RS = value could it not?


On Mar 16, 2015, at 10:47 AM, Josh Mandel <jmandel@gmail.com> = wrote:

Hi Torsten,

You're absolutely correct. The = implementation we're contemplating for SMART Platforms does indeed = derive the "aud" parameter from the actual URL that the client used to = communicate with the RS. Very briefly, the flow is:

1. Electronic Health Record system = tells an app to launch, passing the app its RS endpoint as an issuer = (iss) URL parameter.
2. App queries the RS's issuer = URL to learn what AS to talk to
3. App contacts = AS's authorize endpoint, passing an "aud" param that was the same as the = issuer from step 1.
4. After obtaining a token, app = talks to the RS using that token.

  -Josh


On Mon, Mar 16, 2015 at 10:40 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
I don't think putting an aud into an AT will = help to prevent counterfeit RSs (as long as the aud is nit directly = derived from the original URL used by the client to invoke the = counterfeit RS. as long as the aud is a symbolic name of any kind, the = counterfeit RS will accept ATs for the legitimate RS and just (ab)use = it.

POP on the = contrary helps since the counterfeit RS, in order to send a message to = the legitimate RS, needs to produce a new digitally signed message using = the correct secret, which it doesn't know.

kind regards,
Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker = <Dixie.Baker@martin-blanck.com>:

Using the "aud" parameter makes sense to me.  Good = suggestion.

Authenticating the client to the RS would not address the = counterfeit RS threat. 

-Dixie

 
Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA):  310-791-9671
Mobile:  310-279-2579
=

On Mar 16, 2015, at 6:43 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 = and bearer tokens to help identify the RS to whom the AT should be = issued. It is useful but it's mostly about getting format/content/etc of = the AT correct for the RS rather than it is about preventing possible AT = leaks.

I do think an "aud(iance)" = parameter at both token and authorization endpoints would have utility = beyond the POP work. So defining it independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do = introduce a "audiance" parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-01#section-3.1

It would be possible to have a small spec to define using = "aud" with bearer tokens, however that would be undefined behaviour at = this point.

I = don't know of any clients that would try to access a RS server and then = besed on the error response try and get a access token from the AS = specified in the error.

In POP we are trying to both protect agains that attack and = more common ones like doing a MiM to intercept the AT or the RS being = hacked and leaking the token.

Using "aud" with bearer tokens would be = useful, but probably won't stop the majority of possible AT = leaks.

John = B.


On Mar = 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing = by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the = client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it = didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every = authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-paramete= rs.xhtml . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? The name I used = in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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




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


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

= --Apple-Mail=_BE7760D6-BA57-411A-AC94-53DA6EE7485C-- From nobody Mon Mar 16 11:13:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EBF1A89AF for ; Mon, 16 Mar 2015 11:13: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 WvOYb_B9hmVH for ; Mon, 16 Mar 2015 11:13:17 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003: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 E937A1A89E1 for ; Mon, 16 Mar 2015 11:13:16 -0700 (PDT) Received: by oiag65 with SMTP id g65so45130754oia.2 for ; Mon, 16 Mar 2015 11:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sn492MTyaYD/F5fM+H2zXijpg6ucCxmCIXRpGY46Yhg=; b=OVUAb4dVlcg6SzTVwB1SkJ7rk5L1EnpfTdM8PM/bxinAOBFM7YFLl+xRopNjIOWQcl EC+unLCWz5TnSTCNxx0wz0N+vtWH4+1quUDXX1LWa/SjA3jVYy0AI4poSAtObMDcABZq htpPOI0QuR1ePP8ohCQmtQWj+1NWYKHbjd4NE08KwoU9RgZdzl7qX3XBY4rsFAJ++17b fBp1+4UIYME3cjbChINQnB6p3+Fs4WrTnSbUNpG7tV78g84vDunKv7k9h1GsAnDZUU9M WxeEAelOpTtahTttxefi/jCJlkIj1jHamkhWuPGaLD4wVYte9ASmhEYHpGb5651ok3/m JdUg== X-Received: by 10.202.185.198 with SMTP id j189mr47200718oif.72.1426529596297; Mon, 16 Mar 2015 11:13:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.97.102 with HTTP; Mon, 16 Mar 2015 11:12:56 -0700 (PDT) In-Reply-To: References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> From: Josh Mandel Date: Mon, 16 Mar 2015 11:12:56 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a113ce80ed958d705116bcd46 Archived-At: Cc: Dixie Baker , "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:13:25 -0000 --001a113ce80ed958d705116bcd46 Content-Type: text/plain; charset=ISO-8859-1 Hi Phil, It might help me if you spelled out the phishing scenario you have in mind. The key threat we're attempting to mitigate against with an "aud" param is: 1. Phishing link tells app to launch against RS at https://attacker.com 2. App queries https://attacker.com/metadata (this is a healthcare API called FHIR, which exposes server metadata) to discover which authorization server to talk to. Attacker lies and tells app to authorize at " https://my-real-hospital.com/authorize". 3. App attempts to authorize against " https://my-real-hospital.com/authorize?client_id=...&state=&...&aud=https://attacker.com " 4. The hospital's authorization server rejects the authorization request because https://attacker.com is not a legitimate resource server. Now you may be describing a different attacker where in step #2 the attacker tells the app to authorize against "https://attacker.com/authorize", and this page asks a user to sign in with her hospital credentials. That's indeed a phishing attack that we need separate mitigation against. Happy to think through other mitigations on this front, but it's a separate issue than what I was trying to address with this thread. (Today our primary mitigation for this kind of phishing threat, where attacker.com asks the user to enter her EHR credentials, is user training.) -J On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt wrote: > Josh, > > I'm not sure this helps. It seems to me, a phishing link could tell your > app to launch and pass in any RS value could it not? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Mar 16, 2015, at 10:47 AM, Josh Mandel wrote: > > Hi Torsten, > > You're absolutely correct. The implementation we're contemplating for > SMART Platforms does indeed derive the "aud" parameter from the actual URL > that the client used to communicate with the RS. Very briefly, the flow is: > > 1. Electronic Health Record system tells an app to launch, passing the app > its RS endpoint as an issuer (iss) URL parameter. > 2. App queries the RS's issuer URL to learn what AS to talk to > 3. App contacts AS's authorize endpoint, passing an "aud" param that was > the same as the issuer from step 1. > 4. After obtaining a token, app talks to the RS using that token. > > -Josh > > > On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> I don't think putting an aud into an AT will help to prevent counterfeit >> RSs (as long as the aud is nit directly derived from the original URL used >> by the client to invoke the counterfeit RS. as long as the aud is a >> symbolic name of any kind, the counterfeit RS will accept ATs for the >> legitimate RS and just (ab)use it. >> >> POP on the contrary helps since the counterfeit RS, in order to send a >> message to the legitimate RS, needs to produce a new digitally signed >> message using the correct secret, which it doesn't know. >> >> kind regards, >> Torsten. >> >> >> >> Am 16.03.2015 um 17:40 schrieb Dixie Baker > >: >> >> Using the "aud" parameter makes sense to me. Good suggestion. >> >> Authenticating the client to the RS would not address the counterfeit RS >> threat. >> >> -Dixie >> >> >> Dixie B. Baker, Ph.D. >> Senior Partner >> Martin, Blanck and Associates >> Office (Redondo Beach, CA): 310-791-9671 >> Mobile: 310-279-2579 >> >> On Mar 16, 2015, at 6:43 AM, Brian Campbell >> wrote: >> >> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help >> identify the RS to whom the AT should be issued. It is useful but it's >> mostly about getting format/content/etc of the AT correct for the RS rather >> than it is about preventing possible AT leaks. >> >> I do think an "aud(iance)" parameter at both token and authorization >> endpoints would have utility beyond the POP work. So defining it >> independently might make sense. >> >> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: >> >>> In POP key distribution we do introduce a "audiance" parameter to the >>> token_endpoint. >>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1 >>> >>> It would be possible to have a small spec to define using "aud" with >>> bearer tokens, however that would be undefined behaviour at this point. >>> >>> I don't know of any clients that would try to access a RS server and >>> then besed on the error response try and get a access token from the AS >>> specified in the error. >>> >>> In POP we are trying to both protect agains that attack and more common >>> ones like doing a MiM to intercept the AT or the RS being hacked and >>> leaking the token. >>> >>> Using "aud" with bearer tokens would be useful, but probably won't stop >>> the majority of possible AT leaks. >>> >>> John B. >>> >>> >>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>> Hi Josh, >>> >>> I'm not aware of a common practice to use such a parameter. The WG is >>> instead heading towards authenticated requests to the resource server (see >>> https://tools.ietf.org/html/rfc6819#section-5.4.2). >>> >>> Please take a look onto >>> http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and >>> further drafts on this topic. >>> >>> kind regards, >>> Torsten. >>> >>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>> >>> Hi All, >>> >>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit >>> Resource Server"), RFC6819 describes a threat where a counterfeit resource >>> server tricks a client into obtaining and sharing an access token from a >>> legitimate authorization server. One of the proposed mitigations involves: >>> "telling the authorization server about the resource server endpoint URL in >>> the authorization process." >>> >>> In other words, this mitigation would ask the client to pass an >>> additional parameter when redirecting to the Authorization server's >>> "authorize" URL, effectively something like: >>> >>> https://auth-server/authorize? >>> response_type=code& >>> client_id=123& >>> state=456& >>> scope=read-all& >>> redirect_uri=https://app-server/after-auth& >>> *resource_server_that_told_me_to_authorize_here=https://attacker.com >>> * >>> >>> (And if the authorization server saw a value it didn't like in the >>> final parameter, it would reject the request.) >>> >>> This is obviously not appropriate in every authorization scenario, but >>> it is useful anytime there's a discovery process by which apps learn about >>> authorization servers from resource servers. Since it's something of a >>> common need, I wanted to see if there was any common practice in how to >>> name this parameter, or whether it's worth registering a standard extension >>> at >>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml >>> . (I don't see one there now -- possibly I'm just missing it.) >>> >>> If so, what should it be called? The name I used in the example above >>> is a bit verbose :-) >>> >>> Best, >>> >>> Josh >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a113ce80ed958d705116bcd46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Phil,

It might help me if you spelle= d out the phishing scenario you have in mind. The key threat we're atte= mpting to mitigate against with an "aud" param is:

=
1. Phishing link tells app to launch against RS at https://attacker.com
2.= App queries ht= tps://attacker.com/metadata (this is a healthcare API called FHIR, whic= h exposes server metadata) to discover which authorization server to talk t= o. Attacker lies and tells app to authorize at "https://my-real-hospital.com= /authorize".
4. The hospital's authorization = server rejects the authorization request because https://attacker.com is not a legitimate resou= rce server.

Now you may be describing a different = attacker where in step #2 the attacker tells the app to authorize against &= quot;https://a= ttacker.com/authorize", and this page asks a user to sign in with = her hospital credentials. That's indeed a phishing attack that we need = separate mitigation against. Happy to think through other mitigations on th= is front, but it's a separate issue than what I was trying to address w= ith this thread. (Today our primary mitigation for this kind of phishing th= reat, where attacker.com asks the user = to enter her EHR credentials, is user training.)

&= nbsp; -J

On = Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt <phil.hunt@oracle.com><= /span> wrote:
Josh,

I’m not sure this helps.= It seems to me, a phishing link could tell your app to launch and pass in = any RS value could it not?


On Mar 16, 2015, at 10:47 AM, Josh = Mandel <jmandel@g= mail.com> wrote:

Hi Torsten,

=
You're absolutely correct. The implementation we're cont= emplating for SMART Platforms does indeed derive the "aud" parame= ter from the actual URL that the client used to communicate with the RS. Ve= ry briefly, the flow is:

1. Electronic Health Record sys= tem tells an app to launch, passing the app its RS endpoint as an issuer (i= ss) URL parameter.
2. App queries the RS's issuer URL to lear= n what AS to talk to
3. App contacts AS's authorize endpoint,= passing an "aud" param that was the same as the issuer from step= 1.
4. After obtaining a token, app talks to the RS using that to= ken.

  -Josh


On Mon, Mar 16, 2015 at= 10:40 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
I don= 9;t think putting an aud into an AT will help to prevent counterfeit RSs (a= s long as the aud is nit directly derived from the original URL used by the= client to invoke the counterfeit RS. as long as the aud is a symbolic name= of any kind, the counterfeit RS will accept ATs for the legitimate RS and = just (ab)use it.

POP on the contrary helps since t= he counterfeit RS, in order to send a message to the legitimate RS, needs t= o produce a new digitally signed message using the correct secret, which it= doesn't know.

kind regards,
Torsten= .



Am 16.03.2015 um 17:40 schrieb Dixie Baker <= Dixie.Ba= ker@martin-blanck.com>:

= Using the "aud" parameter makes sense to me.  Good suggestio= n.

Authenticating the client to the RS would not address= the counterfeit RS threat. 

-Dixie

 
Dix= ie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Of= fice (Redondo Beach, CA):  310-791-9671
Mobile:  310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell = <bcampbe= ll@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 a= nd bearer tokens to help identify the RS to whom the AT should be issued. I= t is useful but it's mostly about getting format/content/etc of the AT = correct for the RS rather than it is about preventing possible AT leaks.
I do think an "aud(iance)" parameter at both token and= authorization endpoints would have utility beyond the POP work. So definin= g it independently might make sense.
<= br>
On Sun, Mar 15, 2015 at 11:34 AM, John Bradle= y <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do introd= uce a "audiance" parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-= key-distribution-01#section-3.1

It would be possible= to have a small spec to define using "aud" with bearer tokens, h= owever that would be undefined behaviour at this point.

I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the AS= specified in the error.

In POP we are trying to b= oth protect agains that attack and more common ones like doing a MiM to int= ercept the AT or the RS being hacked and leaking the token.

<= /div>
Using "aud" with bearer tokens would be useful, but pro= bably won't stop the majority of possible AT leaks.

John B.


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.n= et> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2)= .

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-archite= cture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resour= ce server endpoint URL in the authorization process."

In other words, this mitigation would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively= something like:

response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it didn't lik= e in the final parameter, it would reject the request.)

This is obviously not appropriate in every authorization scenario, but it is useful anytime there's a discovery proces= s by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/= assignments/oauth-parameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing= it.)

If so, what should it be called? The name I used in the example above is a bit verbose :-)

Best,

  Josh


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

--001a113ce80ed958d705116bcd46-- From nobody Mon Mar 16 11:16:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148471A89F2 for ; Mon, 16 Mar 2015 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cSYUlYNQ2_xE for ; Mon, 16 Mar 2015 11:16:52 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920E61A1B92 for ; Mon, 16 Mar 2015 11:16:50 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2GIGl1l030800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Mar 2015 18:16:48 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2GIGkgF000875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Mar 2015 18:16:47 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2GIGkbO009865; Mon, 16 Mar 2015 18:16:46 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Mar 2015 11:16:45 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_9BE12F98-5207-4B89-BF39-519BDDCD817D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: Date: Mon, 16 Mar 2015 11:16:44 -0700 Message-Id: <07148D29-F03D-4D89-B61B-7A15DE70BF1C@oracle.com> References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> To: Josh Mandel X-Mailer: Apple Mail (2.2070.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: Dixie Baker , "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:16:57 -0000 --Apple-Mail=_9BE12F98-5207-4B89-BF39-519BDDCD817D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Josh, I was curious how you secure the first step. If your client app is = started by invoking a custom URL, what=92s to stop the attacker using = that and passing in https://attacker.com as the desired RS and audience? Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 16, 2015, at 11:12 AM, Josh Mandel wrote: >=20 > Hi Phil, >=20 > It might help me if you spelled out the phishing scenario you have in = mind. The key threat we're attempting to mitigate against with an "aud" = param is: >=20 > 1. Phishing link tells app to launch against RS at = https://attacker.com > 2. App queries https://attacker.com/metadata = (this is a healthcare API called FHIR, = which exposes server metadata) to discover which authorization server to = talk to. Attacker lies and tells app to authorize at = "https://my-real-hospital.com/authorize = ". > 3. App attempts to authorize against = "https://my-real-hospital.com/authorize?client_id=3D...&state=3D&...&aud=3D= https://attacker.com = " > 4. The hospital's authorization server rejects the authorization = request because https://attacker.com is not a = legitimate resource server. >=20 > Now you may be describing a different attacker where in step #2 the = attacker tells the app to authorize against = "https://attacker.com/authorize ", and = this page asks a user to sign in with her hospital credentials. That's = indeed a phishing attack that we need separate mitigation against. Happy = to think through other mitigations on this front, but it's a separate = issue than what I was trying to address with this thread. (Today our = primary mitigation for this kind of phishing threat, where attacker.com = asks the user to enter her EHR credentials, is = user training.) >=20 > -J >=20 > On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt > wrote: > Josh, >=20 > I=92m not sure this helps. It seems to me, a phishing link could tell = your app to launch and pass in any RS value could it not? >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >> On Mar 16, 2015, at 10:47 AM, Josh Mandel > wrote: >>=20 >> Hi Torsten, >>=20 >> You're absolutely correct. The implementation we're contemplating for = SMART Platforms does indeed derive the "aud" parameter from the actual = URL that the client used to communicate with the RS. Very briefly, the = flow is: >>=20 >> 1. Electronic Health Record system tells an app to launch, passing = the app its RS endpoint as an issuer (iss) URL parameter. >> 2. App queries the RS's issuer URL to learn what AS to talk to >> 3. App contacts AS's authorize endpoint, passing an "aud" param that = was the same as the issuer from step 1. >> 4. After obtaining a token, app talks to the RS using that token. >>=20 >> -Josh >>=20 >>=20 >> On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt = > wrote: >> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>=20 >> POP on the contrary helps since the counterfeit RS, in order to send = a message to the legitimate RS, needs to produce a new digitally signed = message using the correct secret, which it doesn't know. >>=20 >> kind regards, >> Torsten. >>=20 >>=20 >>=20 >> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>=20 >>> Using the "aud" parameter makes sense to me. Good suggestion. >>>=20 >>> Authenticating the client to the RS would not address the = counterfeit RS threat.=20 >>>=20 >>> -Dixie >>>=20 >>> =20 >>> Dixie B. Baker, Ph.D. >>> Senior Partner >>> Martin, Blanck and Associates >>> Office (Redondo Beach, CA): 310-791-9671 >>> Mobile: 310-279-2579 >>> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>>=20 >>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to = help identify the RS to whom the AT should be issued. It is useful but = it's mostly about getting format/content/etc of the AT correct for the = RS rather than it is about preventing possible AT leaks. >>>>=20 >>>> I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So = defining it independently might make sense.=20 >>>>=20 >>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>>=20 >>>> It would be possible to have a small spec to define using "aud" = with bearer tokens, however that would be undefined behaviour at this = point. >>>>=20 >>>> I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the = AS specified in the error. >>>>=20 >>>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>>=20 >>>> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>>=20 >>>>> Hi Josh, >>>>>=20 >>>>> I'm not aware of a common practice to use such a parameter. The WG = is instead heading towards authenticated requests to the resource server = (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>>=20 >>>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>>=20 >>>>> kind regards, >>>>> Torsten. >>>>>=20 >>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>> Hi All, >>>>>>=20 >>>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>>=20 >>>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>>=20 >>>>>> https://auth-server/authorize ? >>>>>> response_type=3Dcode& >>>>>> client_id=3D123& >>>>>> state=3D456& >>>>>> scope=3Dread-all& >>>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>>=20 >>>>>> (And if the authorization server saw a value it didn't like in = the final parameter, it would reject the request.) >>>>>>=20 >>>>>> This is obviously not appropriate in every authorization = scenario, but it is useful anytime there's a discovery process by which = apps learn about authorization servers from resource servers. Since it's = something of a common need, I wanted to see if there was any common = practice in how to name this parameter, or whether it's worth = registering a standard extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>>=20 >>>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Josh >>>>>>=20 >>>>>>=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 >> _______________________________________________ >> 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 --Apple-Mail=_9BE12F98-5207-4B89-BF39-519BDDCD817D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Josh,

I was curious how you secure the first step.  If = your client app is started by invoking a custom URL, what=92s to stop = the attacker using that and passing in https://attacker.com as the desired RS and audience?


On Mar 16, 2015, at 11:12 AM, Josh Mandel <jmandel@gmail.com> = wrote:

Hi Phil,

It might help me if you spelled out the phishing scenario you = have in mind. The key threat we're attempting to mitigate against with = an "aud" param is:

1. Phishing link tells app to launch against RS at https://attacker.com
2. App queries = https://attacker.com/metadata (this is a healthcare API = called FHIR, which exposes server metadata) to discover which = authorization server to talk to. Attacker lies and tells app to = authorize at "https://my-real-hospital.com/authorize".
3. App attempts to authorize against "https://my-real-hospital.com/authorize?client_id=3D...&stat= e=3D&...&aud=3Dhttps://attacker.com"
4. = The hospital's authorization server rejects the authorization request = because https://attacker.com is not a legitimate resource = server.

Now = you may be describing a different attacker where in step #2 the attacker = tells the app to authorize against "https://attacker.com/authorize", and this page asks a = user to sign in with her hospital credentials. That's indeed a phishing = attack that we need separate mitigation against. Happy to think through = other mitigations on this front, but it's a separate issue than what I = was trying to address with this thread. (Today our primary mitigation = for this kind of phishing threat, where attacker.com asks the user to enter her EHR credentials, = is user training.)

  -J

On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Josh,

I=92m not sure this = helps. It seems to me, a phishing link could tell your app to launch and = pass in any RS value could it not?


On Mar 16, 2015, at 10:47 AM, Josh Mandel <jmandel@gmail.com> wrote:

Hi Torsten,

You're absolutely correct. The = implementation we're contemplating for SMART Platforms does indeed = derive the "aud" parameter from the actual URL that the client used to = communicate with the RS. Very briefly, the flow is:

1. Electronic Health Record system = tells an app to launch, passing the app its RS endpoint as an issuer = (iss) URL parameter.
2. App queries the RS's issuer = URL to learn what AS to talk to
3. App contacts = AS's authorize endpoint, passing an "aud" param that was the same as the = issuer from step 1.
4. After obtaining a token, app = talks to the RS using that token.

  -Josh


On Mon, Mar 16, 2015 at 10:40 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
I don't think putting an aud into an AT will = help to prevent counterfeit RSs (as long as the aud is nit directly = derived from the original URL used by the client to invoke the = counterfeit RS. as long as the aud is a symbolic name of any kind, the = counterfeit RS will accept ATs for the legitimate RS and just (ab)use = it.

POP on the = contrary helps since the counterfeit RS, in order to send a message to = the legitimate RS, needs to produce a new digitally signed message using = the correct secret, which it doesn't know.

kind regards,
Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker = <Dixie.Baker@martin-blanck.com>:

Using the "aud" parameter makes sense to me.  Good = suggestion.

Authenticating the client to the RS would not address the = counterfeit RS threat. 

-Dixie

 
Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo = Beach, CA):  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 = and bearer tokens to help identify the RS to whom the AT should be = issued. It is useful but it's mostly about getting format/content/etc of = the AT correct for the RS rather than it is about preventing possible AT = leaks.

I do think an "aud(iance)" = parameter at both token and authorization endpoints would have utility = beyond the POP work. So defining it independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do = introduce a "audiance" parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-01#section-3.1

It would be possible to have a small spec to define using = "aud" with bearer tokens, however that would be undefined behaviour at = this point.

I = don't know of any clients that would try to access a RS server and then = besed on the error response try and get a access token from the AS = specified in the error.

In POP we are trying to both protect agains that attack and = more common ones like doing a MiM to intercept the AT or the RS being = hacked and leaking the token.

Using "aud" with bearer tokens would be = useful, but probably won't stop the majority of possible AT = leaks.

John = B.


On Mar = 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing = by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the = client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it = didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every = authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-paramete= rs.xhtml . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? The name I used = in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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




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


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



= --Apple-Mail=_9BE12F98-5207-4B89-BF39-519BDDCD817D-- From nobody Mon Mar 16 11:27:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AE31A895A for ; Mon, 16 Mar 2015 11:27: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, SPF_PASS=-0.001] autolearn=ham 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 B1ivOdD0iQM5 for ; Mon, 16 Mar 2015 11:27:17 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003: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 EEA291A1DE1 for ; Mon, 16 Mar 2015 11:27:15 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so42467405obd.3 for ; Mon, 16 Mar 2015 11:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2TO7ypKXdnD7XEJC+LZwuyGP2I/ZVOHgTYONf9kDZQw=; b=l8s+EPKUDoxI4A8pIYs4fByI0c24v8TYHkiL6Fjv3s4H6p9ppvxKbAJ+EgIk7z+LIo 2DPF6UkTrz/WKFGK5YIZpoxJH4yplCBvzIBUgc/XVu1onot6uG0IpiBhWdj/ZcQLqnNq lq3DDO6x9DRHCNxQDpurSXq1pcKxwQWN95sZK7w5Ypyw3UfTgLg0pb+kCQK84UB6Fp+H 2yL6knT5D8PSEvdnFPSB4PGjawvp9q4cS0QYK5XJ+eVOW8YAll6WNOeQ5vZQb3Te+6VF Nw4H9ufeCYQId6L1ifLmFiR3EI7HPxADi9/8mGrdqnOHed7QEAkI1qIavLHPS2qIqDPP oo2Q== X-Received: by 10.182.148.71 with SMTP id tq7mr50090020obb.78.1426530435458; Mon, 16 Mar 2015 11:27:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.97.102 with HTTP; Mon, 16 Mar 2015 11:26:55 -0700 (PDT) In-Reply-To: <07148D29-F03D-4D89-B61B-7A15DE70BF1C@oracle.com> References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> <07148D29-F03D-4D89-B61B-7A15DE70BF1C@oracle.com> From: Josh Mandel Date: Mon, 16 Mar 2015 11:26:55 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=089e013a0a7addeaf305116bff7c Archived-At: Cc: Dixie Baker , "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:27:23 -0000 --089e013a0a7addeaf305116bff7c Content-Type: text/plain; charset=ISO-8859-1 Hi Phil, I was curious how you secure the first step. If your client app is started > by invoking a custom URL, what's to stop the attacker using that and > passing in https://attacker.com as the desired RS and audience? An attacker can do just as you've said -- but you didn't say which AS is involved. The goal is that: 1. If the attacker.com RS asks the app to authorize with a *legitimate* AS, that AS will reject the request upon seeing the "aud=https://attacker.com" parameter in the request. This was the main threat I wanted to address with this thread. 2. If the attacker.com RS asks the app to authorize against a *phony* AS, then the end-user is looking at a "classic" phishing attack where the browser is open to "https://attacker.com" and displaying a web page that says "please enter your hospital credentials here". Here, the key mitigation is training end-users not to enter their electronic health record credentials into any site other than the legitimate EHR's authorization server. Again, if you have stronger ideas about how to mitigate #2 we'd love to discuss. But the reason I started this thread was to address #1. One alternative we recognzie is just to ask each client to maintain an explicit whitelist of RS's that it will talk to. We're happy to have this as an option, but 1) this puts a burden on the client, and a client can get it wrong, and 2) we wanted to describe a protocol that allows more dynamic connections. It's certainly a trade-off. -Josh On Mon, Mar 16, 2015 at 11:16 AM, Phil Hunt wrote: > Josh, > > I was curious how you secure the first step. If your client app is > started by invoking a custom URL, what's to stop the attacker using that > and passing in https://attacker.com as the desired RS and audience? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Mar 16, 2015, at 11:12 AM, Josh Mandel wrote: > > Hi Phil, > > It might help me if you spelled out the phishing scenario you have in > mind. The key threat we're attempting to mitigate against with an "aud" > param is: > > 1. Phishing link tells app to launch against RS at https://attacker.com > 2. App queries https://attacker.com/metadata (this is a healthcare API > called FHIR, which exposes server metadata) to discover which authorization > server to talk to. Attacker lies and tells app to authorize at " > https://my-real-hospital.com/authorize". > 3. App attempts to authorize against " > https://my-real-hospital.com/authorize?client_id=...&state=&...&aud=https://attacker.com > " > 4. The hospital's authorization server rejects the authorization request > because https://attacker.com is not a legitimate resource server. > > Now you may be describing a different attacker where in step #2 the > attacker tells the app to authorize against " > https://attacker.com/authorize", and this page asks a user to sign in > with her hospital credentials. That's indeed a phishing attack that we need > separate mitigation against. Happy to think through other mitigations on > this front, but it's a separate issue than what I was trying to address > with this thread. (Today our primary mitigation for this kind of phishing > threat, where attacker.com asks the user to enter her EHR credentials, is > user training.) > > -J > > On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt wrote: > >> Josh, >> >> I'm not sure this helps. It seems to me, a phishing link could tell your >> app to launch and pass in any RS value could it not? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Mar 16, 2015, at 10:47 AM, Josh Mandel wrote: >> >> Hi Torsten, >> >> You're absolutely correct. The implementation we're contemplating for >> SMART Platforms does indeed derive the "aud" parameter from the actual URL >> that the client used to communicate with the RS. Very briefly, the flow is: >> >> 1. Electronic Health Record system tells an app to launch, passing the >> app its RS endpoint as an issuer (iss) URL parameter. >> 2. App queries the RS's issuer URL to learn what AS to talk to >> 3. App contacts AS's authorize endpoint, passing an "aud" param that was >> the same as the issuer from step 1. >> 4. After obtaining a token, app talks to the RS using that token. >> >> -Josh >> >> >> On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> I don't think putting an aud into an AT will help to prevent counterfeit >>> RSs (as long as the aud is nit directly derived from the original URL used >>> by the client to invoke the counterfeit RS. as long as the aud is a >>> symbolic name of any kind, the counterfeit RS will accept ATs for the >>> legitimate RS and just (ab)use it. >>> >>> POP on the contrary helps since the counterfeit RS, in order to send a >>> message to the legitimate RS, needs to produce a new digitally signed >>> message using the correct secret, which it doesn't know. >>> >>> kind regards, >>> Torsten. >>> >>> >>> >>> Am 16.03.2015 um 17:40 schrieb Dixie Baker < >>> Dixie.Baker@martin-blanck.com>: >>> >>> Using the "aud" parameter makes sense to me. Good suggestion. >>> >>> Authenticating the client to the RS would not address the counterfeit RS >>> threat. >>> >>> -Dixie >>> >>> >>> Dixie B. Baker, Ph.D. >>> Senior Partner >>> Martin, Blanck and Associates >>> Office (Redondo Beach, CA): 310-791-9671 >>> Mobile: 310-279-2579 >>> >>> On Mar 16, 2015, at 6:43 AM, Brian Campbell >>> wrote: >>> >>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help >>> identify the RS to whom the AT should be issued. It is useful but it's >>> mostly about getting format/content/etc of the AT correct for the RS rather >>> than it is about preventing possible AT leaks. >>> >>> I do think an "aud(iance)" parameter at both token and authorization >>> endpoints would have utility beyond the POP work. So defining it >>> independently might make sense. >>> >>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley >>> wrote: >>> >>>> In POP key distribution we do introduce a "audiance" parameter to the >>>> token_endpoint. >>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1 >>>> >>>> It would be possible to have a small spec to define using "aud" with >>>> bearer tokens, however that would be undefined behaviour at this point. >>>> >>>> I don't know of any clients that would try to access a RS server and >>>> then besed on the error response try and get a access token from the AS >>>> specified in the error. >>>> >>>> In POP we are trying to both protect agains that attack and more common >>>> ones like doing a MiM to intercept the AT or the RS being hacked and >>>> leaking the token. >>>> >>>> Using "aud" with bearer tokens would be useful, but probably won't stop >>>> the majority of possible AT leaks. >>>> >>>> John B. >>>> >>>> >>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>> Hi Josh, >>>> >>>> I'm not aware of a common practice to use such a parameter. The WG is >>>> instead heading towards authenticated requests to the resource server (see >>>> https://tools.ietf.org/html/rfc6819#section-5.4.2). >>>> >>>> Please take a look onto >>>> http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and >>>> further drafts on this topic. >>>> >>>> kind regards, >>>> Torsten. >>>> >>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>> >>>> Hi All, >>>> >>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit >>>> Resource Server"), RFC6819 describes a threat where a counterfeit resource >>>> server tricks a client into obtaining and sharing an access token from a >>>> legitimate authorization server. One of the proposed mitigations involves: >>>> "telling the authorization server about the resource server endpoint URL in >>>> the authorization process." >>>> >>>> In other words, this mitigation would ask the client to pass an >>>> additional parameter when redirecting to the Authorization server's >>>> "authorize" URL, effectively something like: >>>> >>>> https://auth-server/authorize? >>>> response_type=code& >>>> client_id=123& >>>> state=456& >>>> scope=read-all& >>>> redirect_uri=https://app-server/after-auth& >>>> *resource_server_that_told_me_to_authorize_here=https://attacker.com >>>> * >>>> >>>> (And if the authorization server saw a value it didn't like in the >>>> final parameter, it would reject the request.) >>>> >>>> This is obviously not appropriate in every authorization scenario, >>>> but it is useful anytime there's a discovery process by which apps learn >>>> about authorization servers from resource servers. Since it's something of >>>> a common need, I wanted to see if there was any common practice in how to >>>> name this parameter, or whether it's worth registering a standard extension >>>> at >>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml >>>> . (I don't see one there now -- possibly I'm just missing it.) >>>> >>>> If so, what should it be called? The name I used in the example above >>>> is a bit verbose :-) >>>> >>>> Best, >>>> >>>> Josh >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > --089e013a0a7addeaf305116bff7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Phil,

I was curious how y= ou secure the first step.  If your client app is started by invoking a= custom URL, what’s to stop the attacker using that and passing in&nb= sp;https://attacker.com=  as the desired RS and audience?

A= n attacker can do just as you've said -- but you didn't say which A= S is involved. The goal is that:

1. If the attacker.com RS asks the app to au= thorize with a legitimate AS, that AS will reject the request upon s= eeing the "aud=3Dht= tps://attacker.com" parameter in the request. This was the main th= reat I wanted to address with this thread.

2. If t= he attacker.com RS as= ks the app to authorize against a phony AS, then the end-user is loo= king at a "classic" phishing attack where the browser is open to = "https://attacker.c= om" and displaying a web page that says "please enter your ho= spital credentials here". Here, the key mitigation is training end-use= rs not to enter their electronic health record credentials into any site ot= her than the legitimate EHR's authorization server.

Again, if you have stronger ideas about how to mitigate #2 we'd l= ove to discuss. But the reason I started this thread was to address #1. One= alternative we recognzie is just to ask each client to maintain an explici= t whitelist of RS's that it will talk to. We're happy to have this = as an option, but 1) this puts a burden on the client, and a client can get= it wrong, and 2) we wanted to describe a protocol that allows more dynamic= connections. It's certainly a trade-off.

&nbs= p; -Josh

On = Mon, Mar 16, 2015 at 11:16 AM, Phil Hunt <phil.hunt@oracle.com><= /span> wrote:
= Josh,

I was curious how you secure the first step. = ; If your client app is started by invoking a custom URL, what’s to s= top the attacker using that and passing in https://attacker.com as the desired RS and audience?=


On Mar 16, 2015, at 11:12 AM, Josh = Mandel <jmandel@g= mail.com> wrote:

Hi Phil,

It might help me if you spelled out the phishing scenario you have = in mind. The key threat we're attempting to mitigate against with an &q= uot;aud" param is:

1. Phishing link tells app= to launch against RS at https://attacker.com
2. App queries https://attacker.com/metadata (thi= s is a healthcare API called FHIR, which exposes server metadata) to discov= er which authorization server to talk to. Attacker lies and tells app to au= thorize at "https://my-real-hospital.com/authorize".
<= div>4. The hospital's authorization server rejects the authorization re= quest because https://a= ttacker.com is not a legitimate resource server.

Now you may be describing a different attacker where in step #2 the atta= cker tells the app to authorize against "https://attacker.com/authorize", a= nd this page asks a user to sign in with her hospital credentials. That'= ;s indeed a phishing attack that we need separate mitigation against. Happy= to think through other mitigations on this front, but it's a separate = issue than what I was trying to address with this thread. (Today our primar= y mitigation for this kind of phishing threat, where attacker.com asks the user to enter her EH= R credentials, is user training.)

  -J
<= div class=3D"gmail_extra">
On Mon, Mar 16, 20= 15 at 10:59 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Josh,

I’m not sure this helps. It seems to me, a phishing l= ink could tell your app to launch and pass in any RS value could it not?

On Mar 16, 2015, at 10:47 AM, Josh = Mandel <jmandel@g= mail.com> wrote:

Hi Torsten,

=
You're absolutely correct. The implementation we're cont= emplating for SMART Platforms does indeed derive the "aud" parame= ter from the actual URL that the client used to communicate with the RS. Ve= ry briefly, the flow is:

1. Electronic Health Record sys= tem tells an app to launch, passing the app its RS endpoint as an issuer (i= ss) URL parameter.
2. App queries the RS's issuer URL to lear= n what AS to talk to
3. App contacts AS's authorize endpoint,= passing an "aud" param that was the same as the issuer from step= 1.
4. After obtaining a token, app talks to the RS using that to= ken.

  -Josh


On Mon, Mar 16, 2015 at= 10:40 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
I don't think putt= ing an aud into an AT will help to prevent counterfeit RSs (as long as the = aud is nit directly derived from the original URL used by the client to inv= oke the counterfeit RS. as long as the aud is a symbolic name of any kind, = the counterfeit RS will accept ATs for the legitimate RS and just (ab)use i= t.

POP on the contrary helps since the counterfeit= RS, in order to send a message to the legitimate RS, needs to produce a ne= w digitally signed message using the correct secret, which it doesn't k= now.

kind regards,
Torsten.


<= /div>

Am 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-bla= nck.com>:

Using the &quo= t;aud" parameter makes sense to me.  Good suggestion.

Authenticating the client to the RS would not address the counterfe= it RS threat. 

-Dixie

 
Dix= ie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Of= fice (Redondo Beach, CA):  310-791-9671
Mobile:  310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell = <bcampbe= ll@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 a= nd bearer tokens to help identify the RS to whom the AT should be issued. I= t is useful but it's mostly about getting format/content/etc of the AT = correct for the RS rather than it is about preventing possible AT leaks.
I do think an "aud(iance)" parameter at both token and= authorization endpoints would have utility beyond the POP work. So definin= g it independently might make sense.
<= br>
On Sun, Mar 15, 2015 at 11:34 AM, John Bradle= y <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do introduce a "a= udiance" parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribut= ion-01#section-3.1

It would be possible to have a sm= all spec to define using "aud" with bearer tokens, however that w= ould be undefined behaviour at this point.

I don&#= 39;t know of any clients that would try to access a RS server and then bese= d on the error response try and get a access token from the AS specified in= the error.

In POP we are trying to both protect a= gains that attack and more common ones like doing a MiM to intercept the AT= or the RS being hacked and leaking the token.

Usi= ng "aud" with bearer tokens would be useful, but probably won'= ;t stop the majority of possible AT leaks.

John B.=


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wro= te:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2)= .

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-archite= cture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resour= ce server endpoint URL in the authorization process."

In other words, this mitigation would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively= something like:

response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it didn't lik= e in the final parameter, it would reject the request.)

This is obviously not appropriate in every authorization scenario, but it is useful anytime there's a discovery proces= s by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/= assignments/oauth-parameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing= it.)

If so, what should it be called? The name I used in the example above is a bit verbose :-)

Best,

  Josh


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth


--089e013a0a7addeaf305116bff7c-- From nobody Mon Mar 16 11:39:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E301A8A64 for ; Mon, 16 Mar 2015 11:39:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ATBSkmxkdk-f for ; Mon, 16 Mar 2015 11:39:34 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (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 74F191A8A3D for ; Mon, 16 Mar 2015 11:39:34 -0700 (PDT) Received: by qcaz10 with SMTP id z10so52392819qca.1 for ; Mon, 16 Mar 2015 11:39:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=DWPW40F183roORGCYWRyo46ylIV06ND0d89SNdTP314=; b=l+idS0Cs3Ip8o084t0voo6M09/uffmAf0NqTSJGGiDxlWA0nABVNyjcAnPKt3yfYNk Xs+KCEkSEmf68y6LDS9//mnrYUfgEIvWjRS6pq3aoa8LEkjaEAb1ryb03iS8vVoa0Smp FZfqlfRy6zx/BF+cxZD8t70c6cVHKcRxYda1lf9Hix7OVV7NnkMOVLqKepV/aJ/qLSoX 8XbDj4jWQFGbZf/Y1BRYLsfswBMQyaK+iClmsXDwC+9BmqjkoCFvtWgD46BnkuyPc2gw 4jtmnViyHnenYwLMbYv0DKbWpEvB+sLQ5OLC9zfaTx+kRdxCFzaYOxNWI1UbkjI+MIom amUQ== X-Gm-Message-State: ALoCoQkaxEnKlHXx6bjkLGkpdj2e8UKqkpyGwFUU8QPhO8oNU74BWjKgj0qaGKK7H1qfICkyFa+f X-Received: by 10.140.107.75 with SMTP id g69mr74962337qgf.103.1426531173448; Mon, 16 Mar 2015 11:39:33 -0700 (PDT) Received: from [192.168.8.100] ([181.202.31.7]) by mx.google.com with ESMTPSA id c4sm990291qgf.17.2015.03.16.11.39.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 11:39:32 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_55448752-16BE-49BC-98C3-13D96CB7CC8A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> Date: Mon, 16 Mar 2015 15:39:25 -0300 Message-Id: References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:39:37 -0000 --Apple-Mail=_55448752-16BE-49BC-98C3-13D96CB7CC8A Content-Type: multipart/alternative; boundary="Apple-Mail=_AFA8298B-B377-41BC-9121-717738C9B317" --Apple-Mail=_AFA8298B-B377-41BC-9121-717738C9B317 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian and I were talking about "aud" used as a parameter to the token = endpoint when using a code or refresh token to indicate what RS the = resulting AT will be used at. Sending a audience in the AT wouldn't help prevent the attack being = discussed, though it may stop other sorts of attacks if the RS can tell = if a AT was issued for it or another RS. In PoP having the AS check that you are sending the AT to the correct RS = is less important as the AT if stolen can't be used to replay against = the real AS. Though depending on the app the bogus RS feeding the app the wrong info = may well be a problem as well. John B. > On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = wrote: >=20 > I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >=20 > POP on the contrary helps since the counterfeit RS, in order to send a = message to the legitimate RS, needs to produce a new digitally signed = message using the correct secret, which it doesn't know. >=20 > kind regards, > Torsten. >=20 >=20 >=20 > Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >=20 >> Using the "aud" parameter makes sense to me. Good suggestion. >>=20 >> Authenticating the client to the RS would not address the counterfeit = RS threat.=20 >>=20 >> -Dixie >>=20 >> =20 >> Dixie B. Baker, Ph.D. >> Senior Partner >> Martin, Blanck and Associates >> Office (Redondo Beach, CA): 310-791-9671 >> Mobile: 310-279-2579 >>=20 >> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>=20 >>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help = identify the RS to whom the AT should be issued. It is useful but it's = mostly about getting format/content/etc of the AT correct for the RS = rather than it is about preventing possible AT leaks. >>>=20 >>> I do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.=20 >>>=20 >>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>=20 >>> It would be possible to have a small spec to define using "aud" with = bearer tokens, however that would be undefined behaviour at this point. >>>=20 >>> I don't know of any clients that would try to access a RS server and = then besed on the error response try and get a access token from the AS = specified in the error. >>>=20 >>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>=20 >>> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>=20 >>>> Hi Josh, >>>>=20 >>>> I'm not aware of a common practice to use such a parameter. The WG = is instead heading towards authenticated requests to the resource server = (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>=20 >>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>=20 >>>> kind regards, >>>> Torsten. >>>>=20 >>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>> Hi All, >>>>>=20 >>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>=20 >>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>=20 >>>>> https://auth-server/authorize ? >>>>> response_type=3Dcode& >>>>> client_id=3D123& >>>>> state=3D456& >>>>> scope=3Dread-all& >>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>=20 >>>>> (And if the authorization server saw a value it didn't like in the = final parameter, it would reject the request.) >>>>>=20 >>>>> This is obviously not appropriate in every authorization scenario, = but it is useful anytime there's a discovery process by which apps learn = about authorization servers from resource servers. Since it's something = of a common need, I wanted to see if there was any common practice in = how to name this parameter, or whether it's worth registering a standard = extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>=20 >>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Josh >>>>>=20 >>>>>=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 --Apple-Mail=_AFA8298B-B377-41BC-9121-717738C9B317 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Brian and I were talking about "aud" used as a parameter to = the token endpoint when using a code or refresh token to indicate what = RS the resulting AT will be used at.

Sending a audience in the AT wouldn't = help prevent the attack being discussed,  though it may stop other = sorts of attacks if the RS can tell if a AT was issued for it or another = RS.

In PoP = having the AS check that you are sending the AT to the correct RS is = less important as the AT if stolen can't be used to replay against the = real AS.

Though = depending on the app the bogus RS feeding the app the wrong info may = well be a problem as well.

John B.

On Mar 16, 2015, at 2:40 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

I don't think = putting an aud into an AT will help to prevent counterfeit RSs (as long = as the aud is nit directly derived from the original URL used by the = client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate = RS and just (ab)use it.

POP on the contrary helps since the counterfeit RS, in order = to send a message to the legitimate RS, needs to produce a new digitally = signed message using the correct secret, which it doesn't = know.

kind = regards,
Torsten.



Am 16.03.2015 um 17:40 = schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "aud" parameter makes sense to = me.  Good suggestion.

Authenticating the client to the RS would not address the = counterfeit RS threat. 

-Dixie

 
Dixie B. Baker, Ph.D.
Senior = Partner
Martin, Blanck and Associates
Office = (Redondo Beach, CA):  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at 6:43 = AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

We've used "aud" = (optionally) with OAuth 2 and bearer tokens to help identify the RS to = whom the AT should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I do = think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, = Mar 15, 2015 at 11:34 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do = introduce a "audiance" parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-01#section-3.1

It would be possible to have a small spec to define using = "aud" with bearer tokens, however that would be undefined behaviour at = this point.

I = don't know of any clients that would try to access a RS server and then = besed on the error response try and get a access token from the AS = specified in the error.

In POP we are trying to both protect agains that attack and = more common ones like doing a MiM to intercept the AT or the RS being = hacked and leaking the token.

Using "aud" with bearer tokens would be = useful, but probably won't stop the majority of possible AT = leaks.

John = B.


On Mar = 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing = by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the = client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it = didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every = authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-paramete= rs.xhtml . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? The name I used = in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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




= --Apple-Mail=_AFA8298B-B377-41BC-9121-717738C9B317-- --Apple-Mail=_55448752-16BE-49BC-98C3-13D96CB7CC8A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTYxODM5MjZaMCMGCSqGSIb3DQEJBDEWBBQ3pFwoTPv4kKiJyciTQQXY QK6qbzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBuU15+v/i6Ag6HdAgIaj8e2SNzeakcuDvEHncnIsAcOCdNFNVCKHmd hAkzQHtf4/Yb7GcEEVbR4Fqijkwn+1NF9jGDkI/EEAHZ8LLsd2g38YPIsuymceomm694BK0QYT3j tqutgDCiPrzjzwJJ5NGeBZ34YeCUe3m7Sk3YQRh3cnTak7eHUnCxk9qKc68gKArJlAS9vGDmGunc xjjZMnlor12OG9InqqgYatCvdE1ziw3AsqB/0kxv4kaKRx78QfDe05/a8ZdtjZXHQgPkOAJoxfi9 JEw9KtLPJBA4eKSsgNiP6ZcoEYLpDjTMB0mX6NkAbvZG3NKx2w46ReX4NoFJAAAAAAAA --Apple-Mail=_55448752-16BE-49BC-98C3-13D96CB7CC8A-- From Dixie.Baker@martin-blanck.com Mon Mar 16 16:27:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E51E1ACCE9 for ; Mon, 16 Mar 2015 16:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 zXW4VxW8VXyH for ; Mon, 16 Mar 2015 16:27:53 -0700 (PDT) Received: from cal1-mh779.smtproutes.com (cal1-mh779.smtproutes.com [208.70.91.145]) by ietfa.amsl.com (Postfix) with ESMTP id A74EB1ABC75 for ; Mon, 16 Mar 2015 16:27:53 -0700 (PDT) X-Katharion-ID: 1426548443.43749.cal1-mh779 Received: from remote.martin-blanck.com ([70.91.74.116]) by cal1-mh779.smtproutes.com [(192.69.16.145)] with ESMTP via TCP (TLSv1/TLS_RSA_WITH_AES_128_CBC_SHA); 16 Mar 2015 23:27:23 +0000 Received: from MBA-PRIME.martin.local ([127.0.0.1]) by MBA-PRIME.martin.local ([127.0.0.1]) with mapi; Mon, 16 Mar 2015 19:27:22 -0400 From: Dixie Baker To: John Bradley Date: Mon, 16 Mar 2015 19:27:19 -0400 Thread-Topic: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? Thread-Index: AdBgQMCWTQLbxZyLQkOxM0dwCraSvw== Message-ID: References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B26CE81C549742C9A5C0042B134D0F4Bmartinblanckcom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 17 Mar 2015 07:22:59 -0700 Cc: "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:32:04 -0000 --_000_B26CE81C549742C9A5C0042B134D0F4Bmartinblanckcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The threat that RFC6819 4.6.4 describes is when a client obtains an AT and = then sends it to a counterfeit RS, which then uses the AT to access resourc= es from a legitimate RS, on the end-user's behalf. The suggested countermeasure is a bit difficult to interpret: "Associate t= he endpoint URL of the resource server the client talked to with the access= token (e.g., in an audience field) and validate the association at a legit= imate resource server. The endpoint URL validation policy may be strict (e= xact match) or more relaxed (e.g., same host). This would require telling = the authorization server about the resource server endpoint URL in the auth= orization process." As I read this, the suggestion is to have the client pass the URL of the ba= d RS in the request to the AS (using the audience field). The AS then woul= d include that RS URL in the AT. Then, when the client passes the AT to th= e bad RS, and it passes it on to the good RS, the good RS will check the au= dience field, compare that URL with its own, and refuse the request. -Dixie Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): 310-791-9671 Mobile: 310-279-2579 On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: Brian and I were talking about "aud" used as a parameter to the token endpo= int when using a code or refresh token to indicate what RS the resulting AT= will be used at. Sending a audience in the AT wouldn't help prevent the attack being discuss= ed, though it may stop other sorts of attacks if the RS can tell if a AT w= as issued for it or another RS. In PoP having the AS check that you are sending the AT to the correct RS is= less important as the AT if stolen can't be used to replay against the rea= l AS. Though depending on the app the bogus RS feeding the app the wrong info may= well be a problem as well. John B. On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt > wrote: I don't think putting an aud into an AT will help to prevent counterfeit RS= s (as long as the aud is nit directly derived from the original URL used by= the client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate RS = and just (ab)use it. POP on the contrary helps since the counterfeit RS, in order to send a mess= age to the legitimate RS, needs to produce a new digitally signed message u= sing the correct secret, which it doesn't know. kind regards, Torsten. Am 16.03.2015 um 17:40 schrieb Dixie Baker >: Using the "aud" parameter makes sense to me. Good suggestion. Authenticating the client to the RS would not address the counterfeit RS th= reat. -Dixie Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): 310-791-9671 Mobile: 310-279-2579 On Mar 16, 2015, at 6:43 AM, Brian Campbell > wrote: We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identi= fy the RS to whom the AT should be issued. It is useful but it's mostly abo= ut getting format/content/etc of the AT correct for the RS rather than it i= s about preventing possible AT leaks. I do think an "aud(iance)" parameter at both token and authorization endpoi= nts would have utility beyond the POP work. So defining it independently mi= ght make sense. On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: In POP key distribution we do introduce a "audiance" parameter to the token= _endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributio= n-01#section-3.1 It would be possible to have a small spec to define using "aud" with bearer= tokens, however that would be undefined behaviour at this point. I don't know of any clients that would try to access a RS server and then b= esed on the error response try and get a access token from the AS specified= in the error. In POP we are trying to both protect agains that attack and more common one= s like doing a MiM to intercept the AT or the RS being hacked and leaking t= he token. Using "aud" with bearer tokens would be useful, but probably won't stop the= majority of possible AT leaks. John B. On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt > wrote: Hi Josh, I'm not aware of a common practice to use such a parameter. The WG is inste= ad heading towards authenticated requests to the resource server (see https= ://tools.ietf.org/html/rfc6819#section-5.4.2). Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-arc= hitecture and further drafts on this topic. kind regards, Torsten. Am 03.03.2015 um 18:27 schrieb Josh Mandel: Hi All, In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Se= rver"), RFC6819 describes a threat where a counterfeit resource server tric= ks a client into obtaining and sharing an access token from a legitimate au= thorization server. One of the proposed mitigations involves: "telling the = authorization server about the resource server endpoint URL in the authoriz= ation process." In other words, this mitigation would ask the client to pass an additional = parameter when redirecting to the Authorization server's "authorize" URL, e= ffectively something like: https://auth-server/authorize? response_type=3Dcode& client_id=3D123& state=3D456& scope=3Dread-all& redirect_uri=3Dhttps://app-server/after-auth& resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com (And if the authorization server saw a value it didn't like in the final pa= rameter, it would reject the request.) This is obviously not appropriate in every authorization scenario, but it i= s useful anytime there's a discovery process by which apps learn about auth= orization servers from resource servers. Since it's something of a common n= eed, I wanted to see if there was any common practice in how to name this p= arameter, or whether it's worth registering a standard extension at http://= www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (I don't= see one there now -- possibly I'm just missing it.) If so, what should it be called? The name I used in the example above is a = bit verbose :-) Best, Josh _______________________________________________ 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 --_000_B26CE81C549742C9A5C0042B134D0F4Bmartinblanckcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The threat that RFC6819 4.= 6.4 describes is when a client obtains an AT and then sends it to a counter= feit RS, which then uses the AT to access resources from a legitimate RS, o= n the end-user's behalf.  

The suggested countermea= sure is a bit difficult to interpret:  "Associate the endpoint URL of = the resource server the client talked to with the access token (e.g., in an= audience field) and validate the association at a legitimate resource serv= er.  The endpoint URL validation policy may be strict (exact match) or= more relaxed (e.g., same host).  This would require telling the autho= rization server about the resource server endpoint URL in the authorization= process."  

As I read this, the suggestion i= s to have the client pass the URL of the bad RS in the request to the AS (u= sing the audience field).  The AS then would include that RS URL in th= e AT.  Then, when the client passes the AT to the bad RS, and it passe= s it on to the good RS, the good RS will check the audience field, compare = that URL with its own, and refuse the request.  

<= div>-Dixie



Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):  310-791-9671
Mobile:  31= 0-279-2579

On Mar 16, 2015, at 11:39 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Brian and I were talking about "aud" used as a parameter to= the token endpoint when using a code or refresh token to indicate what RS = the resulting AT will be used at.

Sending a audience in the AT wouldn't help prevent the attack be= ing discussed,  though it may stop other sorts of attacks if the RS ca= n tell if a AT was issued for it or another RS.

In PoP having the AS check that you are send= ing the AT to the correct RS is less important as the AT if stolen can't be= used to replay against the real AS.

Though depending on the app the bogus RS feeding the ap= p the wrong info may well be a problem as well.

John B.

=
On Mar 16, 2015, = at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

I don't think putting an aud into an AT will help to pre= vent counterfeit RSs (as long as the aud is nit directly derived from the o= riginal URL used by the client to invoke the counterfeit RS. as long as the= aud is a symbolic name of any kind, the counterfeit RS will accept ATs for= the legitimate RS and just (ab)use it.

POP on the contrary helps since the counterfeit RS, = in order to send a message to the legitimate RS, needs to produce a new dig= itally signed message using the correct secret, which it doesn't know.

kind regards,
Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker <= ;Dixie.Baker@ma= rtin-blanck.com>:

Using the "aud" parameter = makes sense to me.  Good suggestion.

Authenticating the client to the RS would not address th= e counterfeit RS threat. 

-Dixie

 
Di= xie B. Baker, Ph.D.
Senior Partner
Martin, Blan= ck and Associates
Office (Redondo Beach, CA):  310-791-9= 671
Mobile:  310-279-2579

On Mar 16, 2015, at 6:43 AM,= Brian Campbell <bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 and bearer= tokens to help identify the RS to whom the AT should be issued. It is usef= ul but it's mostly about getting format/content/etc of the AT correct for t= he RS rather than it is about preventing possible AT leaks.
<= br class=3D"">
I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So defining= it independently might make sense.

On Sun, Mar 15, 2015 at = 11:34 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do introduce a "aud= iance" parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distr= ibution-01#section-3.1

It would be possible to have a small spec to define using "aud" with = bearer tokens, however that would be undefined behaviour at this point.

I don't know of any = clients that would try to access a RS server and then besed on the error re= sponse try and get a access token from the AS specified in the error.
=

In POP we are trying t= o both protect agains that attack and more common ones like doing a MiM to = intercept the AT or the RS being hacked and leaking the token.

Using "aud" with bearer token= s would be useful, but probably won't stop the majority of possible AT leak= s.

John B.
<= div class=3D"">


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <= tor= sten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section= -5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-= pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the clien= t to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&= ;
resource_server_that_told_me_to_aut= horize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it did= n't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every authoriz= ation scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://ww= w.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The name I used in= the example above is a bit verbose :-)

Best,

  Josh


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

_______________________________________________
OAuth mailing= list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth


_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





= --_000_B26CE81C549742C9A5C0042B134D0F4Bmartinblanckcom_-- From nobody Tue Mar 17 08:30:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A3B1A6EF2 for ; Tue, 17 Mar 2015 08:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EA5BpIxsFMRe for ; Tue, 17 Mar 2015 08:30:49 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCEC1A6EF0 for ; Tue, 17 Mar 2015 08:30:49 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2HFUlf8028300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Mar 2015 15:30:47 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t2HFUko8029711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2015 15:30:47 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t2HFUjPT024572; Tue, 17 Mar 2015 15:30:46 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Mar 2015 08:30:45 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2E2AA455-C340-4952-AC05-A1737D3F9899" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: Date: Tue, 17 Mar 2015 08:30:43 -0700 Message-Id: <9100736A-1572-4D63-BEE3-540E798E1449@oracle.com> References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> To: Dixie Baker X-Mailer: Apple Mail (2.2070.6) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 15:30:53 -0000 --Apple-Mail=_2E2AA455-C340-4952-AC05-A1737D3F9899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Providing an =E2=80=9Caud=E2=80=9D doesn=E2=80=99t really secure the use = of the token by the client at the RS. It really only helps the RS to = know =E2=80=9Cis this token for me?=E2=80=9D If the RS is bad, it = doesn=E2=80=99t care because it knows it plans to use the =E2=80=9Cacquire= d=E2=80=9D token with the legit RS anyway. That said, by having the client provide the =E2=80=9Caud=E2=80=9D to the = AS, the AS can check if the resource server makes sense for the scope = requested. In RFC6819, we were getting at having some kind binding model that = associates the client to the correct RS as part of the token. For = example, some form of proof-of-posession (see oauth-pop-architecture) = that enables mutual authentication of both client and resource server. = E.g. a token might be encrypted so that only the approved RS can decrypt = it.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 16, 2015, at 4:27 PM, Dixie Baker = wrote: >=20 > The threat that RFC6819 4.6.4 describes is when a client obtains an AT = and then sends it to a counterfeit RS, which then uses the AT to access = resources from a legitimate RS, on the end-user's behalf. =20 >=20 > The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." =20 >=20 > As I read this, the suggestion is to have the client pass the URL of = the bad RS in the request to the AS (using the audience field). The AS = then would include that RS URL in the AT. Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request. =20 >=20 > -Dixie >=20 >=20 >=20 > Dixie B. Baker, Ph.D. > Senior Partner > Martin, Blanck and Associates > Office (Redondo Beach, CA): 310-791-9671 > Mobile: 310-279-2579 >=20 > On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >=20 >> Brian and I were talking about "aud" used as a parameter to the token = endpoint when using a code or refresh token to indicate what RS the = resulting AT will be used at. >>=20 >> Sending a audience in the AT wouldn't help prevent the attack being = discussed, though it may stop other sorts of attacks if the RS can tell = if a AT was issued for it or another RS. >>=20 >> In PoP having the AS check that you are sending the AT to the correct = RS is less important as the AT if stolen can't be used to replay against = the real AS. >>=20 >> Though depending on the app the bogus RS feeding the app the wrong = info may well be a problem as well. >>=20 >> John B. >>=20 >>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>>=20 >>> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>>=20 >>> POP on the contrary helps since the counterfeit RS, in order to send = a message to the legitimate RS, needs to produce a new digitally signed = message using the correct secret, which it doesn't know. >>>=20 >>> kind regards, >>> Torsten. >>>=20 >>>=20 >>>=20 >>> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>>=20 >>>> Using the "aud" parameter makes sense to me. Good suggestion. >>>>=20 >>>> Authenticating the client to the RS would not address the = counterfeit RS threat.=20 >>>>=20 >>>> -Dixie >>>>=20 >>>> =20 >>>> Dixie B. Baker, Ph.D. >>>> Senior Partner >>>> Martin, Blanck and Associates >>>> Office (Redondo Beach, CA): 310-791-9671 >>>> Mobile: 310-279-2579 >>>>=20 >>>> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>>>=20 >>>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to = help identify the RS to whom the AT should be issued. It is useful but = it's mostly about getting format/content/etc of the AT correct for the = RS rather than it is about preventing possible AT leaks. >>>>>=20 >>>>> I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So = defining it independently might make sense.=20 >>>>>=20 >>>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>>>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>>>=20 >>>>> It would be possible to have a small spec to define using "aud" = with bearer tokens, however that would be undefined behaviour at this = point. >>>>>=20 >>>>> I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the = AS specified in the error. >>>>>=20 >>>>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>>>=20 >>>>> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>>>=20 >>>>>> Hi Josh, >>>>>>=20 >>>>>> I'm not aware of a common practice to use such a parameter. The = WG is instead heading towards authenticated requests to the resource = server (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>>>=20 >>>>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>>>=20 >>>>>> kind regards, >>>>>> Torsten. >>>>>>=20 >>>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>>> Hi All, >>>>>>>=20 >>>>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>>>=20 >>>>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>>>=20 >>>>>>> https://auth-server/authorize ? >>>>>>> response_type=3Dcode& >>>>>>> client_id=3D123& >>>>>>> state=3D456& >>>>>>> scope=3Dread-all& >>>>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>>>=20 >>>>>>> (And if the authorization server saw a value it didn't like in = the final parameter, it would reject the request.) >>>>>>>=20 >>>>>>> This is obviously not appropriate in every authorization = scenario, but it is useful anytime there's a discovery process by which = apps learn about authorization servers from resource servers. Since it's = something of a common need, I wanted to see if there was any common = practice in how to name this parameter, or whether it's worth = registering a standard extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>>>=20 >>>>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Josh >>>>>>>=20 >>>>>>>=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2E2AA455-C340-4952-AC05-A1737D3F9899 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Providing an =E2=80=9Caud=E2=80=9D doesn=E2=80=99t really = secure the use of the token by the client at the RS. It really only = helps the RS to know =E2=80=9Cis this token for me?=E2=80=9D  If = the RS is bad, it doesn=E2=80=99t care because it knows it plans to use = the =E2=80=9Cacquired=E2=80=9D token with the legit RS anyway.

That said, by having the = client provide the =E2=80=9Caud=E2=80=9D to the AS, the AS can check if = the resource server makes sense for the scope requested.

In RFC6819, we were = getting at having some kind binding model that associates the client to = the correct RS as part of the token. For example, some form of = proof-of-posession (see oauth-pop-architecture) that enables mutual = authentication of both client and resource server.  E.g. a token = might be encrypted so that only the approved RS can decrypt = it. 


On Mar 16, 2015, at 4:27 PM, Dixie Baker <Dixie.Baker@martin-blanck.com> wrote:

The threat = that RFC6819 4.6.4 describes is when a client obtains an AT and then = sends it to a counterfeit RS, which then uses the AT to access resources = from a legitimate RS, on the end-user's behalf.  

The suggested countermeasure is a bit = difficult to interpret:  "Associate the endpoint URL of the = resource server the client talked to with the access token (e.g., in an = audience field) and validate the association at a legitimate resource = server.  The endpoint URL validation policy may be strict (exact = match) or more relaxed (e.g., same host).  This would require = telling the authorization server about the resource server endpoint URL = in the authorization process."  

As I read this, the suggestion is to = have the client pass the URL of the bad RS in the request to the AS = (using the audience field).  The AS then would include that RS URL = in the AT.  Then, when the client passes the AT to the bad RS, and = it passes it on to the good RS, the good RS will check the audience = field, compare that URL with its own, and refuse the request. =  

-Dixie



Dixie B. Baker, Ph.D.
Senior = Partner
Martin, Blanck and Associates
Office = (Redondo Beach, CA):  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at 11:39 = AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Brian and I were talking about "aud" used as a parameter to = the token endpoint when using a code or refresh token to indicate what = RS the resulting AT will be used at.

Sending a audience in the AT wouldn't = help prevent the attack being discussed,  though it may stop other = sorts of attacks if the RS can tell if a AT was issued for it or another = RS.

In PoP = having the AS check that you are sending the AT to the correct RS is = less important as the AT if stolen can't be used to replay against the = real AS.

Though = depending on the app the bogus RS feeding the app the wrong info may = well be a problem as well.

John B.

On Mar = 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

I don't think = putting an aud into an AT will help to prevent counterfeit RSs (as long = as the aud is nit directly derived from the original URL used by the = client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate = RS and just (ab)use it.

POP on the contrary helps since the counterfeit RS, in order = to send a message to the legitimate RS, needs to produce a new digitally = signed message using the correct secret, which it doesn't = know.

kind = regards,
Torsten.



Am 16.03.2015 um 17:40 = schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "aud" parameter makes sense to = me.  Good suggestion.

Authenticating the client to the RS would not address the = counterfeit RS threat. 

-Dixie

 
Dixie B. Baker, Ph.D.
Senior = Partner
Martin, Blanck and Associates
Office = (Redondo Beach, CA):  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at 6:43 = AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

We've used "aud" = (optionally) with OAuth 2 and bearer tokens to help identify the RS to = whom the AT should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I do = think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, = Mar 15, 2015 at 11:34 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do = introduce a "audiance" parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-01#section-3.1

It would be possible to have a small spec to define using = "aud" with bearer tokens, however that would be undefined behaviour at = this point.

I = don't know of any clients that would try to access a RS server and then = besed on the error response try and get a access token from the AS = specified in the error.

In POP we are trying to both protect agains that attack and = more common ones like doing a MiM to intercept the AT or the RS being = hacked and leaking the token.

Using "aud" with bearer tokens would be = useful, but probably won't stop the majority of possible AT = leaks.

John = B.


On Mar = 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing = by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the = client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it = didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every = authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-paramete= rs.xhtml . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? The name I used = in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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





_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_2E2AA455-C340-4952-AC05-A1737D3F9899-- From nobody Tue Mar 17 08:49:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81651A6FFE for ; Tue, 17 Mar 2015 08:49:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 fuVpsIllEJQO for ; Tue, 17 Mar 2015 08:49:41 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (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 3EF4B1A6FF1 for ; Tue, 17 Mar 2015 08:49:41 -0700 (PDT) Received: by qcyi15 with SMTP id i15so12404228qcy.0 for ; Tue, 17 Mar 2015 08:49:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=EoTWmPpakDUFzPJj/iCB5zCagjE5tbpgIhczhw6CoDA=; b=UL7ilBek9R7Okby0i8Rhm4fsNZIysVhUFwgxYxAd3rQxuwNriYz2YwhU5ncelLj4ts 5746+lYI5DFwSk5C9cnKq5cJZ92xhIQCYvhOkTGfrxlmquzU3OMeWRz3sdbPNabRMs4Y fLlbSmsDLxx65l5gSaVXXifvNhCexmuD0MLclHaSxyvvI2Q0Wp3dB9ssvyBAI++XjdRz UF+V/hevSEj2RezhUWq0h71vb6iT6hNWxKCNVW9lMflyrhsKspcE1Kp4+wXeYN55Qdmn 6/N26jbQa7rTgkj5hBGJOWtNCydCKmiYOcWxydAhN/dlqP2IWxHtPi9n/E9KphLVBJr0 OVkA== X-Gm-Message-State: ALoCoQlhZTo1JLsjscU2jLhst6y20YeqPpHjxKjmozKXf/GT5pNW6K7NWtSaFzdPwKoPe/Uht3kA X-Received: by 10.140.97.203 with SMTP id m69mr81103346qge.39.1426607380325; Tue, 17 Mar 2015 08:49:40 -0700 (PDT) Received: from [192.168.8.100] ([181.202.4.92]) by mx.google.com with ESMTPSA id 132sm9827183qhf.17.2015.03.17.08.49.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 08:49:39 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_65C33D02-2C94-4399-BE2E-321BE1C83F25"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Tue, 17 Mar 2015 12:49:33 -0300 Message-Id: References: <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> To: Dixie Baker X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 15:49:45 -0000 --Apple-Mail=_65C33D02-2C94-4399-BE2E-321BE1C83F25 Content-Type: multipart/alternative; boundary="Apple-Mail=_D17EA5FF-876C-475C-BFA8-C7ACBE7A3B69" --Apple-Mail=_D17EA5FF-876C-475C-BFA8-C7ACBE7A3B69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You could do that, but it is probably safer for the AS to know what RS = it can issue tokens for and refuse to issue a token for RS A to a client = asking for a token with RS X as the aud. John B. > On Mar 16, 2015, at 8:27 PM, Dixie Baker = wrote: >=20 > The threat that RFC6819 4.6.4 describes is when a client obtains an AT = and then sends it to a counterfeit RS, which then uses the AT to access = resources from a legitimate RS, on the end-user's behalf. =20 >=20 > The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." =20 >=20 > As I read this, the suggestion is to have the client pass the URL of = the bad RS in the request to the AS (using the audience field). The AS = then would include that RS URL in the AT. Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request. =20 >=20 > -Dixie >=20 >=20 >=20 > Dixie B. Baker, Ph.D. > Senior Partner > Martin, Blanck and Associates > Office (Redondo Beach, CA): 310-791-9671 > Mobile: 310-279-2579 >=20 > On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >=20 >> Brian and I were talking about "aud" used as a parameter to the token = endpoint when using a code or refresh token to indicate what RS the = resulting AT will be used at. >>=20 >> Sending a audience in the AT wouldn't help prevent the attack being = discussed, though it may stop other sorts of attacks if the RS can tell = if a AT was issued for it or another RS. >>=20 >> In PoP having the AS check that you are sending the AT to the correct = RS is less important as the AT if stolen can't be used to replay against = the real AS. >>=20 >> Though depending on the app the bogus RS feeding the app the wrong = info may well be a problem as well. >>=20 >> John B. >>=20 >>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>>=20 >>> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>>=20 >>> POP on the contrary helps since the counterfeit RS, in order to send = a message to the legitimate RS, needs to produce a new digitally signed = message using the correct secret, which it doesn't know. >>>=20 >>> kind regards, >>> Torsten. >>>=20 >>>=20 >>>=20 >>> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>>=20 >>>> Using the "aud" parameter makes sense to me. Good suggestion. >>>>=20 >>>> Authenticating the client to the RS would not address the = counterfeit RS threat.=20 >>>>=20 >>>> -Dixie >>>>=20 >>>> =20 >>>> Dixie B. Baker, Ph.D. >>>> Senior Partner >>>> Martin, Blanck and Associates >>>> Office (Redondo Beach, CA): 310-791-9671 >>>> Mobile: 310-279-2579 >>>>=20 >>>> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>>>=20 >>>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to = help identify the RS to whom the AT should be issued. It is useful but = it's mostly about getting format/content/etc of the AT correct for the = RS rather than it is about preventing possible AT leaks. >>>>>=20 >>>>> I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So = defining it independently might make sense.=20 >>>>>=20 >>>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>>>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>>>=20 >>>>> It would be possible to have a small spec to define using "aud" = with bearer tokens, however that would be undefined behaviour at this = point. >>>>>=20 >>>>> I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the = AS specified in the error. >>>>>=20 >>>>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>>>=20 >>>>> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>>>=20 >>>>>> Hi Josh, >>>>>>=20 >>>>>> I'm not aware of a common practice to use such a parameter. The = WG is instead heading towards authenticated requests to the resource = server (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>>>=20 >>>>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>>>=20 >>>>>> kind regards, >>>>>> Torsten. >>>>>>=20 >>>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>>> Hi All, >>>>>>>=20 >>>>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>>>=20 >>>>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>>>=20 >>>>>>> https://auth-server/authorize ? >>>>>>> response_type=3Dcode& >>>>>>> client_id=3D123& >>>>>>> state=3D456& >>>>>>> scope=3Dread-all& >>>>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>>>=20 >>>>>>> (And if the authorization server saw a value it didn't like in = the final parameter, it would reject the request.) >>>>>>>=20 >>>>>>> This is obviously not appropriate in every authorization = scenario, but it is useful anytime there's a discovery process by which = apps learn about authorization servers from resource servers. Since it's = something of a common need, I wanted to see if there was any common = practice in how to name this parameter, or whether it's worth = registering a standard extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>>>=20 >>>>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Josh >>>>>>>=20 >>>>>>>=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 >=20 --Apple-Mail=_D17EA5FF-876C-475C-BFA8-C7ACBE7A3B69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
You could do that, but it is probably safer = for the AS to know what RS it can issue tokens for and refuse to issue a = token for RS A to a client asking for a token with RS X as the = aud.

John = B.
On Mar 16, 2015, at 8:27 PM, Dixie Baker <Dixie.Baker@martin-blanck.com> wrote:

The threat = that RFC6819 4.6.4 describes is when a client obtains an AT and then = sends it to a counterfeit RS, which then uses the AT to access resources = from a legitimate RS, on the end-user's behalf.  

The suggested countermeasure is a bit = difficult to interpret:  "Associate the endpoint URL of the = resource server the client talked to with the access token (e.g., in an = audience field) and validate the association at a legitimate resource = server.  The endpoint URL validation policy may be strict (exact = match) or more relaxed (e.g., same host).  This would require = telling the authorization server about the resource server endpoint URL = in the authorization process."  

As I read this, the suggestion is to = have the client pass the URL of the bad RS in the request to the AS = (using the audience field).  The AS then would include that RS URL = in the AT.  Then, when the client passes the AT to the bad RS, and = it passes it on to the good RS, the good RS will check the audience = field, compare that URL with its own, and refuse the request. =  

-Dixie



Dixie B. Baker, Ph.D.
Senior = Partner
Martin, Blanck and Associates
Office = (Redondo Beach, CA):  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at 11:39 = AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Brian and I were talking about "aud" used as a parameter to = the token endpoint when using a code or refresh token to indicate what = RS the resulting AT will be used at.

Sending a audience in the AT wouldn't = help prevent the attack being discussed,  though it may stop other = sorts of attacks if the RS can tell if a AT was issued for it or another = RS.

In PoP = having the AS check that you are sending the AT to the correct RS is = less important as the AT if stolen can't be used to replay against the = real AS.

Though = depending on the app the bogus RS feeding the app the wrong info may = well be a problem as well.

John B.

On Mar = 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

I don't think = putting an aud into an AT will help to prevent counterfeit RSs (as long = as the aud is nit directly derived from the original URL used by the = client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate = RS and just (ab)use it.

POP on the contrary helps since the counterfeit RS, in order = to send a message to the legitimate RS, needs to produce a new digitally = signed message using the correct secret, which it doesn't = know.

kind = regards,
Torsten.



Am 16.03.2015 um 17:40 = schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "aud" parameter makes sense to = me.  Good suggestion.

Authenticating the client to the RS would not address the = counterfeit RS threat. 

-Dixie

 
Dixie B. Baker, Ph.D.
Senior = Partner
Martin, Blanck and Associates
Office = (Redondo Beach, CA):  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at 6:43 = AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

We've used "aud" = (optionally) with OAuth 2 and bearer tokens to help identify the RS to = whom the AT should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I do = think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, = Mar 15, 2015 at 11:34 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In POP key distribution we do = introduce a "audiance" parameter to the token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-01#section-3.1

It would be possible to have a small spec to define using = "aud" with bearer tokens, however that would be undefined behaviour at = this point.

I = don't know of any clients that would try to access a RS server and then = besed on the error response try and get a access token from the AS = specified in the error.

In POP we are trying to both protect agains that attack and = more common ones like doing a MiM to intercept the AT or the RS being = hacked and leaking the token.

Using "aud" with bearer tokens would be = useful, but probably won't stop the majority of possible AT = leaks.

John = B.


On Mar = 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing = by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would ask the = client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it = didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in every = authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-paramete= rs.xhtml . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? The name I used = in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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






= --Apple-Mail=_D17EA5FF-876C-475C-BFA8-C7ACBE7A3B69-- --Apple-Mail=_65C33D02-2C94-4399-BE2E-321BE1C83F25 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTcxNTQ5MzNaMCMGCSqGSIb3DQEJBDEWBBSmiklzvFqPX10WjJ/tfk7U MXHQ1zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB0OMVHkUNqaNNfMhB6DwtGqFMNWq61gbentUxxxrQX+/UVVSUk0AUF hb0FpbpbQpL6Hpszbim3LIH97h/CMI8ihxZWZfzNSjcDTUQbBdygnl/cub0FSIGAYS74h/L3Tkin 8YOx/UMD6pQZWk8jVvHpSh8CczRETJ6ujbpRobFEkAGdWcLjQ5OEVk9AhcZmoMobE4z+73SdOGt6 uE5qyCGp/TNgMKKOLdhoNbGktSSIa354Pbz1CEVdBkHaJthsl4WAT7hYkyp3KdHJzb+2NOsVFhrq KqNclTX6bTZUglVPNHDfNKaZgZ7dggrsT2NszEsmpJaHYIJL6kn53st8zox+AAAAAAAA --Apple-Mail=_65C33D02-2C94-4399-BE2E-321BE1C83F25-- From nobody Tue Mar 17 12:10:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4D91A1B67 for ; Tue, 17 Mar 2015 12:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 rXjF3waNOZQa for ; Tue, 17 Mar 2015 12:10:46 -0700 (PDT) Received: from nm48-vm10.bullet.mail.bf1.yahoo.com (nm48-vm10.bullet.mail.bf1.yahoo.com [216.109.114.235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35871A1A6E for ; Tue, 17 Mar 2015 12:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426619445; bh=R/KjzJwiMO9R8Cl91MhgZbxBSnxq/iIb4QfFw4R/PGE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=PvuogUrDOMXqa4Vrn8uNjRl6W1aloFl+0kbkbXqRHPC2NxSNLJKmW9zQP7zhEl6o/lSKtVOuYPlF4OT1c6t/gcycZ1T0Y624/9WykxZIhVjasG6CaqYiT9hjRBrNSNaEDk959G/XCBNXoy3ICbiro7NWS4EVKkvMlPLGYWKzbsONJ5M4SW1D6+PZ/5mJPs8Suf3CGns9+z2J3CBYin1Lyv6sc8Mgk4Gx2909PA6bkeV/vPmVeMLz0tWc8kJOfPHwPwVBZgDuPlip6I3qzlaaXBNuf2PY64zoH/bt6/KjVa8zIaxpnbimEXN8GHhgk+1yvWZw1wtZVAAni0WmHmLiWw== Received: from [98.139.215.141] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 19:10:45 -0000 Received: from [98.139.212.241] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 19:10:45 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 19:10:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 23838.82287.bm@omp1050.mail.bf1.yahoo.com X-YMail-OSG: sKyaNPwVM1k89HxpgtsqsF65klnlF8Rq_.wWIvypbk1zE8Njd7dNvkOIzMbq74K qbZmwwtIji8Aq3pHd3ZOb7UwFLlGtLt1drMTNJnVAYiJrlg5TUSKs7_6AWi_iiaB3nnEe5RvLIpc nRtZ8IHYpOd7kwdxsCNoLoEFyVdN77x6n7O6wNnPiTG1Z7YMKGNLFGsxGU3lXZdz0SUHuPB2rQEa ONzG7sUAYhED5tn.KafoFAUJsORzNx4cKEGZg4kcKiDujwE2vzY38dCHJVQUwyS44wuPPzsUp7Th oeqhsH42_44.PgLqMtTX1fihz3BSom1T_R58z54z7xcUfiS9melydbZqMtX5UHqMTnjwAze9jU1i 0uzLjK.IXfgLrOkEz6lxBnBZu9WwPVnzbqHUJ4Ge.fY86.ZIOcOjoDi63bYfN80Agg_wV46TNGv5 SAYgoWJQvtDQuR0O7QOwH5dPskf.jmBy24qfeQDyZWz5.4UQ5Vl2EQe1eD28HAijpv.0D4z8iuog _OgsPX9ENK.v1mQJH8Mi_g6uNL1RoAUZub2VIHb9_k3CWwf2qkfbrsjXf0QT74DGDUsoL_sDa4QI 0BHnHO8xN4PLi_w9m4SPpbbIoQ0PH3fXHQ5Ug00wWGmtFhtWi1G2dru_WtEXhMTTrvnfa0caGOkL z2DP9acOYF23tGVQasRtchUiqpmlPJfSvtemIm5wh76oiDn1Byglxxqk- Received: by 76.13.27.6; Tue, 17 Mar 2015 19:10:44 +0000 Date: Tue, 17 Mar 2015 19:10:43 +0000 (UTC) From: Bill Mills To: John Bradley , Dixie Baker Message-ID: <365324430.1826238.1426619443876.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1826237_1452831367.1426619443841" Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 19:10:49 -0000 ------=_Part_1826237_1452831367.1426619443841 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This may have been hashed out already and I missed it, but "aud" just becom= es another kind of scope, correct? =20 On Tuesday, March 17, 2015 8:50 AM, John Bradley w= rote: =20 You could do that, but it is probably safer for the AS to know what RS it = can issue tokens for and refuse to issue a token for RS A to a client askin= g for a token with RS X as the aud. John B. On Mar 16, 2015, at 8:27 PM, Dixie Baker wr= ote: The threat that RFC6819 4.6.4 describes is when a client obtains an AT and = then sends it to a counterfeit RS, which then uses the AT to access resourc= es from a legitimate RS, on the end-user's behalf. =C2=A0 The suggested countermeasure is a bit difficult to interpret: =C2=A0"Associ= ate the endpoint URL of the resource server the client talked to with the a= ccess token (e.g., in an audience field) and validate the association at a = legitimate resource server. =C2=A0The endpoint URL validation policy may be= strict (exact match) or more relaxed (e.g., same host). =C2=A0This would r= equire telling the authorization server about the resource server endpoint = URL in the authorization process." =C2=A0 As I read this, the suggestion is to have the client pass the URL of the ba= d RS in the request to the AS (using the audience field). =C2=A0The AS then= would include that RS URL in the AT. =C2=A0Then, when the client passes th= e AT to the bad RS, and it passes it on to the good RS, the good RS will ch= eck the audience field, compare that URL with its own, and refuse the reque= st. =C2=A0 -Dixie Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 11:39 AM, John Bradley wrote: Brian and I were talking about "aud" used as a parameter to the token endpo= int when using a code or refresh token to indicate what RS the resulting AT= will be used at. Sending a audience in the AT wouldn't help prevent the attack being discuss= ed, =C2=A0though it may stop other sorts of attacks if the RS can tell if a= AT was issued for it or another RS. In PoP having the AS check that you are sending the AT to the correct RS is= less important as the AT if stolen can't be used to replay against the rea= l AS. Though depending on the app the bogus RS feeding the app the wrong info may= well be a problem as well. John B. On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = wrote: I don't think putting an aud into an AT will help to prevent counterfeit RS= s (as long as the aud is nit directly derived from the original URL used by= the client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate RS = and just (ab)use it. POP on the contrary helps since the counterfeit RS, in order to send a mess= age to the legitimate RS, needs to produce a new digitally signed message u= sing the correct secret, which it doesn't know. kind regards,Torsten. Am 16.03.2015 um 17:40 schrieb Dixie Baker : Using the "aud" parameter makes sense to me. =C2=A0Good suggestion. Authenticating the client to the RS would not address the counterfeit RS th= reat.=C2=A0 -Dixie =C2=A0 Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 6:43 AM, Brian Campbell wr= ote: We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identi= fy the RS to whom the AT should be issued. It is useful but it's mostly abo= ut getting format/content/etc of the AT correct for the RS rather than it i= s about preventing possible AT leaks. I do think an "aud(iance)" parameter at both token and authorization endpoi= nts would have utility beyond the POP work. So defining it independently mi= ght make sense.=20 On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: In POP key distribution we do introduce a "audiance" parameter to the token= _endpoint.=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distri= bution-01#section-3.1 It would be possible to have a small spec to define using "aud" with bearer= tokens, however that would be undefined behaviour at this point. I don't know of any clients that would try to access a RS server and then b= esed on the error response try and get a access token from the AS specified= in the error. In POP we are trying to both protect agains that attack and more common one= s like doing a MiM to intercept the AT or the RS being hacked and leaking t= he token. Using "aud" with bearer tokens would be useful, but probably won't stop the= majority of possible AT leaks. John B. On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = wrote: Hi Josh, =20 I'm not aware of a common practice to use such a parameter. The WG is inst= ead heading towards authenticated requests to the resource server (see http= s://tools.ietf.org/html/rfc6819#section-5.4.2).=20 =20 Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-ar= chitecture and further drafts on this topic. =20 kind regards, Torsten. =20 Am 03.03.2015 um 18:27 schrieb Josh Mandel: =20 Hi All,=20 In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource = Server"), RFC6819 describes a threat where a counterfeit resource server tr= icks a client into obtaining and sharing an access token from a legitimate = authorization server. One of the proposed mitigations involves: "telling th= e authorization server about the resource server endpoint URL in the author= ization process."=20 In other words, this mitigation would ask the client to pass an additiona= l parameter when redirecting to the Authorization server's "authorize" URL,= effectively something like:=20 https://auth-server/authorize? response_type=3Dcode& client_id=3D123& st= ate=3D456& scope=3Dread-all& redirect_uri=3Dhttps://app-server/after-auth& resourc= e_server_that_told_me_to_authorize_here=3Dhttps://attacker.com =20 (And if the authorization server saw a value it didn't like in the final = parameter, it would reject the request.)=20 This is obviously not appropriate in every authorization scenario, but it= is useful anytime there's a discovery process by which apps learn about au= thorization servers from resource servers. Since it's something of a common= need, I wanted to see if there was any common practice in how to name this= parameter, or whether it's worth registering a standard extension at=C2=A0= http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (= I don't see one there now -- possibly I'm just missing it.)=20 If so, what should it be called? The name I used in the example above is = a bit verbose :-)=20 Best,=20 =C2=A0 Josh =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 _______________________________________________ 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 ------=_Part_1826237_1452831367.1426619443841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This may have been hashed out already and I missed it, but "aud" just beco= mes another kind of scope, correct?




= On Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com>= wrote:


You could do that, but= it is probably safer for the AS to know what RS it can issue tokens for an= d refuse to issue a token for RS A to a client asking for a token with RS X= as the aud.

John B.
On Mar 16, 2015, at 8:27 PM, Dixie Baker <= Dixie.Baker@martin-blanck.com> wrote:
The threat that RFC6819 = 4.6.4 describes is when a client obtains an AT and then sends it to a count= erfeit RS, which then uses the AT to access resources from a legitimate RS,= on the end-user's behalf.  

The sugges= ted countermeasure is a bit difficult to interpret:  "Associate the en= dpoint URL of the resource server the client talked to with the access toke= n (e.g., in an audience field) and validate the association at a legitimate= resource server.  The endpoint URL validation policy may be strict (e= xact match) or more relaxed (e.g., same host).  This would require tel= ling the authorization server about the resource server endpoint URL in the= authorization process."  

As I r= ead this, the suggestion is to have the client pass the URL of the bad RS i= n the request to the AS (using the audience field).  The AS then would= include that RS URL in the AT.  Then, when the client passes the AT t= o the bad RS, and it passes it on to the good RS, the good RS will check th= e audience field, compare that URL with its own, and refuse the request. &n= bsp;

-Dixie



Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 11:39 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:

Brian and I were talking about "aud" us= ed as a parameter to the token endpoint when using a code or refresh token = to indicate what RS the resulting AT will be used at.

Sending a audience in the AT wouldn't help prevent the attack bei= ng discussed,  though it may stop other sorts of attacks if the RS can= tell if a AT was issued for it or another RS.

In PoP having the AS check that you are sending the AT to the corr= ect RS is less important as the AT if stolen can't be used to replay agains= t the real AS.

Though depending on t= he app the bogus RS feeding the app the wrong info may well be a problem as= well.

John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <= torsten@lodderstedt.net> wrote:

I don't think putting an aud into an AT will help to = prevent counterfeit RSs (as long as the aud is nit directly derived from th= e original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept ATs = for the legitimate RS and just (ab)use it.

POP on the contrary helps since the counterfeit RS, in order to send a= message to the legitimate RS, needs to produce a new digitally signed mess= age using the correct secret, which it doesn't know.

kind regards,
Torsten.



Am 16.03.2015 um 17:40= schrieb Dixie Baker <Dixie.Baker@martin-blanck.co= m>:

Using th= e "aud" parameter makes sense to me.  Good suggestion.

Authenticating the client to the RS would not address the c= ounterfeit RS threat. 

-Dixie

<= /div>
 
Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv7798094098" ymailto=3D"mailto= :bcampbell@pingidentity.com" target=3D"_blank" href=3D"mailto:bcampbell@pin= gidentity.com">bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 and bea= rer tokens to help identify the RS to whom the AT should be issued. It is u= seful but it's mostly about getting format/content/etc of the AT correct fo= r the RS rather than it is about preventing possible AT leaks.

I do think an "aud(iance)" parameter at both token and authorization en= dpoints would have utility beyond the POP work. So defining it independentl= y might make sense.

On Sun, Mar 15, 2015 at 11:34 AM,= John Bradley <ve7jtb@ve7jtb.com= > wrote:
In POP key distribution we do introduce a "audiance" p= arameter to the token_endpoint. https://tools.ietf.or= g/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1

It would be possible to have a small spec to define u= sing "aud" with bearer tokens, however that would be undefined behaviour at= this point.

I don't know of any clien= ts that would try to access a RS server and then besed on the error respons= e try and get a access token from the AS specified in the error.

In POP we are trying to both protect agains that= attack and more common ones like doing a MiM to intercept the AT or the RS= being hacked and leaking the token.

U= sing "aud" with bearer tokens would be useful, but probably won't stop the = majority of possible AT leaks.

John B= .


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt &= lt;torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Toke= n Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would = ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_= server_that_told_me_to_authorize_here=3Dht= tps://attacker.com

(And if the authorization server saw a= value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in e= very authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-p= arameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The n= ame I used in the example above is a bit verbose :-)

Best,

  Josh


________________________________________=
_______
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org=
/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oau= th
<= br clear=3D"none" class=3D"yiv7798094098">

_________________________________________= ______
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth







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


------=_Part_1826237_1452831367.1426619443841-- From nobody Tue Mar 17 12:41:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AF71A88A5 for ; Tue, 17 Mar 2015 12:41:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 3GTR3IuCuueL for ; Tue, 17 Mar 2015 12:41:03 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (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 EEEAA1A88B9 for ; Tue, 17 Mar 2015 12:41:02 -0700 (PDT) Received: by qgf3 with SMTP id 3so18278654qgf.3 for ; Tue, 17 Mar 2015 12:41:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=/tlJPS2AgN8HNV463xWqJqQZVTTT4X4G1uWx0txVewA=; b=N0PMkbXtr0DKWEah+aJw6x5DiXI9qktxeYaK2X/BYmMWShzD/JHd/myU8hbmi8xQQ8 eJ7OIFEYpIU78CYWuIqOXraSzWIdPV0an/rl0ss2ts28Ea5tiMyGS0Gl8ieJLcy32kYv WBnmD4NBBZn6umOMFnxOiEacfiJo+cgl4Hx42DWW9nqGpqGt3+JzqEBdSuROjqdx8DbL PxZpi67gpfF+DSWKjolH15tZeiOKSHybYE/2EWdaaJkt7PdHK84Y+DotOO/GKLOqlZK5 KmWFFbLfr2MEcybTWRf1hDPJfb2+SGinfOFqD+WaIc21w0Yqe4vtXjn3cuhm5gE0ZC/+ ZYtw== X-Gm-Message-State: ALoCoQm3twBEy3IInGVywGrW02werePCZn9uvNCYDHaXHNgbDJh+vllnT4gMtneJHvFS/Fw8ngdG X-Received: by 10.140.147.131 with SMTP id 125mr87866450qht.81.1426621261877; Tue, 17 Mar 2015 12:41:01 -0700 (PDT) Received: from [192.168.8.100] ([181.202.4.92]) by mx.google.com with ESMTPSA id f77sm10265526qka.9.2015.03.17.12.40.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 12:41:00 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E3BC768D-A14F-4FFC-8923-08AA80493DD3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <365324430.1826238.1426619443876.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Mar 2015 16:40:55 -0300 Message-Id: <7B21E963-C247-4452-B9DF-4D370433511B@ve7jtb.com> References: <365324430.1826238.1426619443876.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 19:41:10 -0000 --Apple-Mail=_E3BC768D-A14F-4FFC-8923-08AA80493DD3 Content-Type: multipart/alternative; boundary="Apple-Mail=_9CD7D738-8321-4F66-81CF-F13FE5B82C37" --Apple-Mail=_9CD7D738-8321-4F66-81CF-F13FE5B82C37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii People have been overloading scope names to create implicit audience. =20= The problem is that clients need to know via some magic method that you = need to ask for scope "purple" to get write access to RS 2. Having an explicit "aud" parameter gives clients a way to communicate to = the AS what RS they are asking for a token for.=20 the security issue is that if a client discovers a API out via some out = of band mechanism the OAuth error code can tell the client go to AS X = and ask for Scope Y. =20 Unfortunately without POP tokens or at-least passing the URI of the RS = to the AS via "aud", a bad RS could get a legitimate client to give it a = token that can be replayed at a legitimate RS. This was one of the issues that Eran Hammer-Lahav was particularly = concerned about. =20 I think I proposed a "aud" parameter to the token endpoint back then as = a alternative to requiring HMAC tokens, but that got lost in the = confusion at the time. At that time though people were not yet thinking about interoperable = OAuth API, only relatively tightly bound clients that were = preconfigured for the API endpoints they were using. In Health and other places we are starting to see standard clients that = discover API endpoints and configure themselves based on a users = Identity to use a arbitrary OAuth AS, moving into federation of AT. That is one of the reasons POP will be important, as it prevents RS from = misusing federated tokens by presenting them at other RS. The simplest thing to do is have the client say what RS it is trying to = access explicitly (The "aud" parameter), and including an audience in = the AT. to protect against malicious RS. PoP is the step up that also protects against tokens being intercepted = and replayed by another client. John B. > On Mar 17, 2015, at 4:10 PM, Bill Mills = wrote: >=20 > This may have been hashed out already and I missed it, but "aud" just = becomes another kind of scope, correct? >=20 >=20 >=20 >=20 > On Tuesday, March 17, 2015 8:50 AM, John Bradley = wrote: >=20 >=20 > You could do that, but it is probably safer for the AS to know what RS = it can issue tokens for and refuse to issue a token for RS A to a client = asking for a token with RS X as the aud. >=20 > John B. >> On Mar 16, 2015, at 8:27 PM, Dixie Baker = > = wrote: >>=20 >=20 > The threat that RFC6819 4.6.4 describes is when a client obtains an AT = and then sends it to a counterfeit RS, which then uses the AT to access = resources from a legitimate RS, on the end-user's behalf. =20 >=20 > The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." =20 >=20 > As I read this, the suggestion is to have the client pass the URL of = the bad RS in the request to the AS (using the audience field). The AS = then would include that RS URL in the AT. Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request. =20 >=20 > -Dixie >=20 >=20 >=20 > Dixie B. Baker, Ph.D. > Senior Partner > Martin, Blanck and Associates > Office (Redondo Beach, CA): 310-791-9671 > Mobile: 310-279-2579 >=20 > On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >=20 >=20 > Brian and I were talking about "aud" used as a parameter to the token = endpoint when using a code or refresh token to indicate what RS the = resulting AT will be used at. >=20 > Sending a audience in the AT wouldn't help prevent the attack being = discussed, though it may stop other sorts of attacks if the RS can tell = if a AT was issued for it or another RS. >=20 > In PoP having the AS check that you are sending the AT to the correct = RS is less important as the AT if stolen can't be used to replay against = the real AS. >=20 > Though depending on the app the bogus RS feeding the app the wrong = info may well be a problem as well. >=20 > John B. >=20 >> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>=20 >=20 > I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >=20 > POP on the contrary helps since the counterfeit RS, in order to send a = message to the legitimate RS, needs to produce a new digitally signed = message using the correct secret, which it doesn't know. >=20 > kind regards, > Torsten. >=20 >=20 >=20 > Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >=20 >=20 > Using the "aud" parameter makes sense to me. Good suggestion. >=20 > Authenticating the client to the RS would not address the counterfeit = RS threat.=20 >=20 > -Dixie >=20 > =20 > Dixie B. Baker, Ph.D. > Senior Partner > Martin, Blanck and Associates > Office (Redondo Beach, CA): 310-791-9671 > Mobile: 310-279-2579 >=20 > On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >=20 >> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help = identify the RS to whom the AT should be issued. It is useful but it's = mostly about getting format/content/etc of the AT correct for the RS = rather than it is about preventing possible AT leaks. >>=20 >> I do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.=20 >>=20 >> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >> In POP key distribution we do introduce a "audiance" parameter to the = token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>=20 >> It would be possible to have a small spec to define using "aud" with = bearer tokens, however that would be undefined behaviour at this point. >>=20 >> I don't know of any clients that would try to access a RS server and = then besed on the error response try and get a access token from the AS = specified in the error. >>=20 >> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>=20 >> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>=20 >> John B. >>=20 >>=20 >>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>=20 >>> Hi Josh, >>>=20 >>> I'm not aware of a common practice to use such a parameter. The WG = is instead heading towards authenticated requests to the resource server = (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>=20 >>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>=20 >>> kind regards, >>> Torsten. >>>=20 >>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>> Hi All, >>>>=20 >>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>=20 >>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>=20 >>>> https://auth-server/authorize ? >>>> response_type=3Dcode& >>>> client_id=3D123& >>>> state=3D456& >>>> scope=3Dread-all& >>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>> resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com= >>>>=20 >>>> (And if the authorization server saw a value it didn't like in the = final parameter, it would reject the request.) >>>>=20 >>>> This is obviously not appropriate in every authorization scenario, = but it is useful anytime there's a discovery process by which apps learn = about authorization servers from resource servers. Since it's something = of a common need, I wanted to see if there was any common practice in = how to name this parameter, or whether it's worth registering a standard = extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>=20 >>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>=20 >>>> Best, >>>>=20 >>>> Josh >>>>=20 >>>>=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 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_9CD7D738-8321-4F66-81CF-F13FE5B82C37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii People have been overloading scope names to create implicit = audience.   

The problem is that clients need to know via some magic = method that you need to ask for scope "purple" to get write access to RS = 2.

Having an = explicit "aud" parameter gives clients a way to communicate to the AS = what RS they are asking for a token for. 

the security issue is = that if a client discovers a API out via some out of band mechanism the = OAuth error code can tell the client go to AS X and ask for Scope Y. =  

Unfortunately without POP tokens or at-least passing the URI = of the RS to the AS via "aud", a bad RS could get a legitimate client to = give it a token that can be replayed at a legitimate RS.

This was one of the = issues that Eran Hammer-Lahav was particularly concerned about. =  

I think = I proposed a "aud" parameter to the token endpoint back then as a = alternative to requiring HMAC tokens, but that got lost in the confusion = at the time.

At = that time though people were not yet thinking about interoperable OAuth = API,  only relatively tightly bound clients that were preconfigured = for the API endpoints they were using.

In Health and other places we are = starting to see standard clients that discover API endpoints and = configure themselves based on a users Identity to use a arbitrary OAuth = AS, moving into federation of AT.

That is one of the reasons POP will be = important, as it prevents RS from misusing federated tokens by = presenting them at other RS.

The simplest thing to do is have the = client say what RS it is trying to access explicitly (The "aud" = parameter), and including an audience in the AT.  to protect = against malicious RS.

PoP is the step up that also protects against tokens being = intercepted and replayed by another client.

John B.

On Mar 17, 2015, at 4:10 PM, Bill Mills = <wmills_92105@yahoo.com> wrote:

This may have been hashed out already and I missed it, but = "aud" just becomes another kind of scope, correct?




On Tuesday, = March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


=
You could do that, but it is = probably safer for the AS to know what RS it can issue tokens for and = refuse to issue a token for RS A to a client asking for a token with RS = X as the aud.

John B.
On Mar 16, 2015, at 8:27 PM, Dixie Baker <Dixie.Baker@martin-blanck.co= m> wrote:

The threat that RFC6819 4.6.4 describes = is when a client obtains an AT and then sends it to a counterfeit RS, = which then uses the AT to access resources from a legitimate RS, on the = end-user's behalf.  

The suggested = countermeasure is a bit difficult to interpret:  "Associate the = endpoint URL of the resource server the client talked to with the access = token (e.g., in an audience field) and validate the association at a = legitimate resource server.  The endpoint URL validation policy may = be strict (exact match) or more relaxed (e.g., same host).  This = would require telling the authorization server about the resource server = endpoint URL in the authorization process."  

As I read = this, the suggestion is to have the client pass the URL of the bad RS in = the request to the AS (using the audience field).  The AS then = would include that RS URL in the AT.  Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request.  

-Dixie



Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 11:39 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Brian and I were talking about "aud" = used as a parameter to the token endpoint when using a code or refresh = token to indicate what RS the resulting AT will be used at.

Sending a = audience in the AT wouldn't help prevent the attack being discussed, =  though it may stop other sorts of attacks if the RS can tell if a = AT was issued for it or another RS.

In PoP having the AS check that you are sending = the AT to the correct RS is less important as the AT if stolen can't be = used to replay against the real AS.

Though depending on the app the bogus RS feeding = the app the wrong info may well be a problem as well.

John = B.

On = Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

I = don't think putting an aud into an AT will help to prevent counterfeit = RSs (as long as the aud is nit directly derived from the original URL = used by the client to invoke the counterfeit RS. as long as the aud is a = symbolic name of any kind, the counterfeit RS will accept ATs for the = legitimate RS and just (ab)use it.

POP on the contrary helps since the counterfeit = RS, in order to send a message to the legitimate RS, needs to produce a = new digitally signed message using the correct secret, which it doesn't = know.

kind = regards,
Torsten.



Am = 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.co= m>:

Using the "aud" parameter makes sense to me.  Good = suggestion.

Authenticating = the client to the RS would not address the counterfeit RS = threat. 

-Dixie

 
Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 6:43 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

We've used "aud" (optionally) = with OAuth 2 and bearer tokens to help identify the RS to whom the AT = should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I= do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:
In POP key = distribution we do introduce a "audiance" parameter to the = token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distr= ibution-01#section-3.1

It would be = possible to have a small spec to define using "aud" with bearer tokens, = however that would be undefined behaviour at this point.

I don't know = of any clients that would try to access a RS server and then besed on = the error response try and get a access token from the AS specified in = the error.

In POP we are = trying to both protect agains that attack and more common ones like = doing a MiM to intercept the AT or the RS being hacked and leaking the = token.

Using "aud" = with bearer tokens would be useful, but probably won't stop the majority = of possible AT leaks.

John = B.


On Mar 15, 2015, at 2:18 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.i= etf.org/html/rfc6819#section-5.4.2).

Please take a look onto http= ://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access = Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation = would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?<= /div>
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&= amp;
resource_server_that_told_me_to_authorize_here=3D<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv7798094098" = target=3D"_blank" = href=3D"https://attacker.com/">https://attacker.com

(And if the authorization server = saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate = in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.x= html . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? = The name I used in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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







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


=

= --Apple-Mail=_9CD7D738-8321-4F66-81CF-F13FE5B82C37-- --Apple-Mail=_E3BC768D-A14F-4FFC-8923-08AA80493DD3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTcxOTQwNTZaMCMGCSqGSIb3DQEJBDEWBBTn6xKI9KlbtvpjksuIPdyd xw1A1zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCKKDFmCwmN/EpQyFeU14FPdJgpYo6fe8GHB8YJWlIJO3w3INI/pWCz wjSrPH8yBg/ZnC9o2iyRL58TbHeSBIOIE7/3a/yosToWGEvJWfkqm1QQrH0eIfxh8YGOou01/n9V HSrdseDS2TECAE6hF3lhmcfOP17QgAUSAHqDTQB2meQDnoalp/leq1PeDllNCJphWHlEFygABjU2 pSqBeMfjH5YIQ1LzTy5RHbC5N8rOJ4IeVr7ARNq0XLBparu/IZbiv8Qzis1CfKsnqApOhQB89/hw TElq/8lYvhXpfGfaHavQrUr0xwVrNjWByWxuEuCZe4qRmdYUryIp5170WgH1AAAAAAAA --Apple-Mail=_E3BC768D-A14F-4FFC-8923-08AA80493DD3-- From nobody Tue Mar 17 13:39:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB51A88E7 for ; Tue, 17 Mar 2015 13:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 oWl06H626zVU for ; Tue, 17 Mar 2015 13:39:46 -0700 (PDT) Received: from nm40-vm1.bullet.mail.bf1.yahoo.com (nm40-vm1.bullet.mail.bf1.yahoo.com [72.30.239.209]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13CA1A8893 for ; Tue, 17 Mar 2015 13:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426624785; bh=7XbkI5V7lc15+0VEF7iqL6i3sjG6IbJCAT+ekZb/KmM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=aL781GA4tlh9DSGD0jrK1vU44zuGLOZZRL4DK1Pm05wR7vpPX2BNRg+7HF8zNaaZ4w02JHCNyZmLLJ5btmMISNCeXxZxK0k3hbSrZ0PAsM8BJneP52VVNQe5QE7VLg8sNTwsCy+xk/fqJbkJk6frosBrorsoy3JGTMgs2K16+dnIOgPCO34LxgMXCUpg6Bl/p1vrNI1Qh53+P0Ah+XMDBLUSzE+nbCvidnTbqkheFlOEZujndXfveJlrRfQUbCTaNgiCAzEiMWwcEeXREapR/sGDCLUeGWQIKVmDiVct03MtHabBe2h4pD6A4KsWCM25lIEmQFjoIsfHX+ujmMQ8Zg== Received: from [66.196.81.172] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 20:39:45 -0000 Received: from [98.139.212.210] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 20:39:45 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 20:39:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 34015.69760.bm@omp1019.mail.bf1.yahoo.com X-YMail-OSG: phhA1UcVM1mpKmqojrjmdzRHohmeFkqOJj1yVrjFQA2iHT8V3mjhu38gIyqZUGR q_Dx0n6ttPjXkvi7uq1tLuCwluPhazvqm_iK3Ke4Jrw4mn2xw4O.s634Vnwbnb11oK3QCijikHHU Owx42jGXn1_XwrHKnOH8FZ.gtRr_TOeZfgqNxpFvYbiVFyNWBseURhJAQHFag.wXrBKN4SXNWDeZ ASqfUfZvT6z1zceAxGTik.v0SHL3ohwkiRd5wK3gioLI0cNUNa3zw6wQEbZnEUqCrZ32gZxtasW3 70jUcJlgw.1SJL5UyXDxqUZCpLdhNm0j3x_mhhx3EqnKR0.5ZCY.XPJkCmXcx2Rejb.OqXFMYNv8 .kMe7G6hHDL0OjD6YF19j3Cdmzn4QGOVuBTseT5bh1P9tYYyFVnoEaYfWDwqr1fGV_oNzKg5gZDp nhl7iQhW13LQNp8.poGSsZe0Bm9oTHgY69LQf51WzhSFerQ6HJsVW1P3X408dKK0hSa9ymc6fVPw _yFoKyRYYtrkInFOW1XZSTL0hBBwi4hyJgUffJfH8jikbvOAThbTodNn37JdUOQCsfRx2jscsB6K JulFMy1IZZO2vTxhB8a6lS.hb7UjV3uwhT65PEVIjMh6eLdiMK3q46tkr29vZEPUwovttUpABS2B KFt8nAqpA0G.DMFxODW1W7PXzNToEnIakXQJu Received: by 66.196.80.145; Tue, 17 Mar 2015 20:39:44 +0000 Date: Tue, 17 Mar 2015 20:39:44 +0000 (UTC) From: Bill Mills To: John Bradley Message-ID: <40858890.46948.1426624784094.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <7B21E963-C247-4452-B9DF-4D370433511B@ve7jtb.com> References: <7B21E963-C247-4452-B9DF-4D370433511B@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_46947_49817674.1426624784071" Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 20:39:50 -0000 ------=_Part_46947_49817674.1426624784071 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think it's "overloading scope names" to use them that way. =C2=A0Th= e aud value(s) could as easily be carried in scope as anywhere. =C2=A0Nothi= ng says a scope can't be "https://foo.com", and that Foo.com requires that = scope to be present for a token to be accepted. =C2=A0I would not make it f= oo.com-read-mail for example. If it's more convenient to put it in aud I can accept that, but it's the sa= me functionality and can be implemented in scopes now.=20 On Tuesday, March 17, 2015 12:41 PM, John Bradley = wrote: =20 People have been overloading scope names to create implicit audience. =C2= =A0=C2=A0 The problem is that clients need to know via some magic method that you nee= d to ask for scope "purple" to get write access to RS 2. Having an explicit "aud" parameter gives clients a way to communicate to th= e AS what RS they are asking for a token for.=C2=A0 the security issue is that if a client discovers a API out via some out of = band mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y. =C2=A0 Unfortunately without POP tokens or at-least passing the URI of the RS to t= he AS via "aud", a bad RS could get a legitimate client to give it a token = that can be replayed at a legitimate RS. This was one of the issues that Eran Hammer-Lahav was particularly concerne= d about. =C2=A0 I think I proposed a "aud" parameter to the token endpoint back then as a a= lternative to requiring HMAC tokens, but that got lost in the confusion at = the time. At that time though people were not yet thinking about interoperable OAuth = API, =C2=A0only relatively tightly bound clients that were preconfigured fo= r the API endpoints they were using. In Health and other places we are starting to see standard clients that dis= cover API endpoints and configure themselves based on a users Identity to u= se a arbitrary OAuth AS, moving into federation of AT. That is one of the reasons POP will be important, as it prevents RS from mi= susing federated tokens by presenting them at other RS. The simplest thing to do is have the client say what RS it is trying to acc= ess explicitly (The "aud" parameter), and including an audience in the AT. = =C2=A0to protect against malicious RS. PoP is the step up that also protects against tokens being intercepted and = replayed by another client. John B. On Mar 17, 2015, at 4:10 PM, Bill Mills wrote: This may have been hashed out already and I missed it, but "aud" just becom= es another kind of scope, correct? =20 On Tuesday, March 17, 2015 8:50 AM, John Bradley w= rote: =20 You could do that, but it is probably safer for the AS to know what RS it = can issue tokens for and refuse to issue a token for RS A to a client askin= g for a token with RS X as the aud. John B. On Mar 16, 2015, at 8:27 PM, Dixie Baker wr= ote: The threat that RFC6819 4.6.4 describes is when a client obtains an AT and = then sends it to a counterfeit RS, which then uses the AT to access resourc= es from a legitimate RS, on the end-user's behalf. =C2=A0 The suggested countermeasure is a bit difficult to interpret: =C2=A0"Associ= ate the endpoint URL of the resource server the client talked to with the a= ccess token (e.g., in an audience field) and validate the association at a = legitimate resource server. =C2=A0The endpoint URL validation policy may be= strict (exact match) or more relaxed (e.g., same host). =C2=A0This would r= equire telling the authorization server about the resource server endpoint = URL in the authorization process." =C2=A0 As I read this, the suggestion is to have the client pass the URL of the ba= d RS in the request to the AS (using the audience field). =C2=A0The AS then= would include that RS URL in the AT. =C2=A0Then, when the client passes th= e AT to the bad RS, and it passes it on to the good RS, the good RS will ch= eck the audience field, compare that URL with its own, and refuse the reque= st. =C2=A0 -Dixie Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 11:39 AM, John Bradley wrote: Brian and I were talking about "aud" used as a parameter to the token endpo= int when using a code or refresh token to indicate what RS the resulting AT= will be used at. Sending a audience in the AT wouldn't help prevent the attack being discuss= ed, =C2=A0though it may stop other sorts of attacks if the RS can tell if a= AT was issued for it or another RS. In PoP having the AS check that you are sending the AT to the correct RS is= less important as the AT if stolen can't be used to replay against the rea= l AS. Though depending on the app the bogus RS feeding the app the wrong info may= well be a problem as well. John B. On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = wrote: I don't think putting an aud into an AT will help to prevent counterfeit RS= s (as long as the aud is nit directly derived from the original URL used by= the client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate RS = and just (ab)use it. POP on the contrary helps since the counterfeit RS, in order to send a mess= age to the legitimate RS, needs to produce a new digitally signed message u= sing the correct secret, which it doesn't know. kind regards,Torsten. Am 16.03.2015 um 17:40 schrieb Dixie Baker : Using the "aud" parameter makes sense to me. =C2=A0Good suggestion. Authenticating the client to the RS would not address the counterfeit RS th= reat.=C2=A0 -Dixie =C2=A0 Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 6:43 AM, Brian Campbell wr= ote: We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identi= fy the RS to whom the AT should be issued. It is useful but it's mostly abo= ut getting format/content/etc of the AT correct for the RS rather than it i= s about preventing possible AT leaks. I do think an "aud(iance)" parameter at both token and authorization endpoi= nts would have utility beyond the POP work. So defining it independently mi= ght make sense.=20 On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: In POP key distribution we do introduce a "audiance" parameter to the token= _endpoint.=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distri= bution-01#section-3.1 It would be possible to have a small spec to define using "aud" with bearer= tokens, however that would be undefined behaviour at this point. I don't know of any clients that would try to access a RS server and then b= esed on the error response try and get a access token from the AS specified= in the error. In POP we are trying to both protect agains that attack and more common one= s like doing a MiM to intercept the AT or the RS being hacked and leaking t= he token. Using "aud" with bearer tokens would be useful, but probably won't stop the= majority of possible AT leaks. John B. On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = wrote: Hi Josh, =20 I'm not aware of a common practice to use such a parameter. The WG is inst= ead heading towards authenticated requests to the resource server (see http= s://tools.ietf.org/html/rfc6819#section-5.4.2).=20 =20 Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-ar= chitecture and further drafts on this topic. =20 kind regards, Torsten. =20 Am 03.03.2015 um 18:27 schrieb Josh Mandel: =20 Hi All,=20 In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource = Server"), RFC6819 describes a threat where a counterfeit resource server tr= icks a client into obtaining and sharing an access token from a legitimate = authorization server. One of the proposed mitigations involves: "telling th= e authorization server about the resource server endpoint URL in the author= ization process."=20 In other words, this mitigation would ask the client to pass an additiona= l parameter when redirecting to the Authorization server's "authorize" URL,= effectively something like:=20 https://auth-server/authorize? response_type=3Dcode& client_id=3D123& st= ate=3D456& scope=3Dread-all& redirect_uri=3Dhttps://app-server/after-auth& resourc= e_server_that_told_me_to_authorize_here=3Dhttps://attacker.com =20 (And if the authorization server saw a value it didn't like in the final = parameter, it would reject the request.)=20 This is obviously not appropriate in every authorization scenario, but it= is useful anytime there's a discovery process by which apps learn about au= thorization servers from resource servers. Since it's something of a common= need, I wanted to see if there was any common practice in how to name this= parameter, or whether it's worth registering a standard extension at=C2=A0= http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (= I don't see one there now -- possibly I'm just missing it.)=20 If so, what should it be called? The name I used in the example above is = a bit verbose :-)=20 Best,=20 =C2=A0 Josh =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 _______________________________________________ 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 ------=_Part_46947_49817674.1426624784071 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think it's "overloading scope = names" to use them that way.  The aud value(s) could as easily be carr= ied in scope as anywhere.  Nothing says a scope can't be "https://foo.= com", and that Foo.com requires that scope to be present for a token to be = accepted.  I would not make it foo.com-read-mail for example.

If it's more convenient to put it in = aud I can accept that, but it's the same functionality and can be implement= ed in scopes now.



On Tuesday, March 17,= 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
 <= /div>

People have been overloading scope names to create implicit audience. &n= bsp; 

The problem is that clients need = to know via some magic method that you need to ask for scope "purple" to ge= t write access to RS 2.

Having an explicit "= aud" parameter gives clients a way to communicate to the AS what RS they ar= e asking for a token for. 
<= div class=3D"yiv3782689420">
the security issue is that if a client disco= vers a API out via some out of band mechanism the OAuth error code can tell= the client go to AS X and ask for Scope Y.  

Unfortunately without POP tokens or at-least passing the URI o= f the RS to the AS via "aud", a bad RS could get a legitimate client to giv= e it a token that can be replayed at a legitimate RS.

This was one of the issues that Eran Hammer-Lahav was parti= cularly concerned about.  

I thin= k I proposed a "aud" parameter to the token endpoint back then as a alterna= tive to requiring HMAC tokens, but that got lost in the confusion at the ti= me.

At that time though people were no= t yet thinking about interoperable OAuth API,  only relatively tightly= bound clients that were preconfigured for the API endpoints they were usin= g.

In Health and other places we are s= tarting to see standard clients that discover API endpoints and configure t= hemselves based on a users Identity to use a arbitrary OAuth AS, moving int= o federation of AT.

That is one of the= reasons POP will be important, as it prevents RS from misusing federated t= okens by presenting them at other RS.
= The simplest thing to do is have the client say what RS it is trying to acc= ess explicitly (The "aud" parameter), and including an audience in the AT. =  to protect against malicious RS.
PoP is the step up that also protects against tokens being intercepted and= replayed by another client.

John B.

On Mar 17, 2015, at 4:10 PM, Bill = Mills <wmills_92105@yahoo.com> wrote:

This may have been hashed out alr= eady and I missed it, but "aud" just becomes another kind of scope, correct= ?




= On Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:


You could do that, but it is probably safer for the AS to know what = RS it can issue tokens for and refuse to issue a token for RS A to a client= asking for a token with RS X as the aud.

John B.
On Mar 16, 2015, at 8:27 PM, Dixie Baker <= Dixie.Baker@martin-blanck.com> wrote:

The threat that RFC6819= 4.6.4 describes is when a client obtains an AT and then sends it to a coun= terfeit RS, which then uses the AT to access resources from a legitimate RS= , on the end-user's behalf.  

The sugge= sted countermeasure is a bit difficult to interpret:  "Associate the e= ndpoint URL of the resource server the client talked to with the access tok= en (e.g., in an audience field) and validate the association at a legitimat= e resource server.  The endpoint URL validation policy may be strict (= exact match) or more relaxed (e.g., same host).  This would require te= lling the authorization server about the resource server endpoint URL in th= e authorization process."  

As I = read this, the suggestion is to have the client pass the URL of the bad RS = in the request to the AS (using the audience field).  The AS then woul= d include that RS URL in the AT.  Then, when the client passes the AT = to the bad RS, and it passes it on to the good RS, the good RS will check t= he audience field, compare that URL with its own, and refuse the request. &= nbsp;

-Dixie



Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 11:39 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:

<= div class=3D"yiv3782689420" style=3D"word-wrap:break-word;">Brian and I wer= e talking about "aud" used as a parameter to the token endpoint when using = a code or refresh token to indicate what RS the resulting AT will be used a= t.

<= /div>
Sending a audience in the AT wouldn't hel= p prevent the attack being discussed,  though it may stop other sorts = of attacks if the RS can tell if a AT was issued for it or another RS.

In PoP having the AS check that you are se= nding the AT to the correct RS is less important as the AT if stolen can't = be used to replay against the real AS.
Though depending on the app the bogus RS feeding the app the wrong info ma= y well be a problem as well.

John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodd= erstedt <torsten@lodderstedt.net> wrote:

I don't= think putting an aud into an AT will help to prevent counterfeit RSs (as l= ong as the aud is nit directly derived from the original URL used by the cl= ient to invoke the counterfeit RS. as long as the aud is a symbolic name of= any kind, the counterfeit RS will accept ATs for the legitimate RS and jus= t (ab)use it.

POP on the contrary help= s since the counterfeit RS, in order to send a message to the legitimate RS= , needs to produce a new digitally signed message using the correct secret,= which it doesn't know.

kind regards,<= /div>
Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "au= d" parameter makes sense to me.  Good suggestion.

Authenticating the client to the RS would not address the counte= rfeit RS threat. 

-Dixie

=
 
Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv3782689420" ymailto=3D"mailto= :bcampbell@pingidentity.com" target=3D"_blank" href=3D"mailto:bcampbell@pin= gidentity.com">bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 and bea= rer tokens to help identify the RS to whom the AT should be issued. It is u= seful but it's mostly about getting format/content/etc of the AT correct fo= r the RS rather than it is about preventing possible AT leaks.

I do think an "aud(iance)" parameter at both token and authorization en= dpoints would have utility beyond the POP work. So defining it independentl= y might make sense.

On Sun, Mar 15, 2015 at 11:34 AM,= John Bradley <ve7jtb@ve7jtb.com= > wrote:
In POP key distribution we do introduce a "audiance" p= arameter to the token_endpoint. https://tools.ietf.or= g/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1

It would be possible to have a small spec to define u= sing "aud" with bearer tokens, however that would be undefined behaviour at= this point.

I don't know of any clien= ts that would try to access a RS server and then besed on the error respons= e try and get a access token from the AS specified in the error.

In POP we are trying to both protect agains that= attack and more common ones like doing a MiM to intercept the AT or the RS= being hacked and leaking the token.

U= sing "aud" with bearer tokens would be useful, but probably won't stop the = majority of possible AT leaks.

John B= .


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt &= lt;torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Toke= n Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would = ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_= server_that_told_me_to_authorize_here=3Dht= tps://attacker.com

(And if the authorization server saw a= value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in e= very authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-p= arameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The n= ame I used in the example above is a bit verbose :-)

Best,

  Josh


________________________________________=
_______
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org=
/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oau= th
<= br clear=3D"none" class=3D"yiv3782689420">

_________________________________________= ______
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth



<= /div>

------=_Part_46947_49817674.1426624784071-- From nobody Tue Mar 17 13:54:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E011A88EF for ; Tue, 17 Mar 2015 13:54:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 dYgJnmwAYLjm for ; Tue, 17 Mar 2015 13:54:01 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (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 3EB691A88EC for ; Tue, 17 Mar 2015 13:54:01 -0700 (PDT) Received: by qcbkw5 with SMTP id kw5so21053119qcb.2 for ; Tue, 17 Mar 2015 13:54:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=sb9Wd8qu5B3IOU1/BcX6lLq/reXJ52E2RISAd0eKGgQ=; b=Qo+TNfjLfVX3UIicYKPlohCIMlGi2dS/uKnZ+z9JOrPQYiKt5uW7c1Idc/isgCPBXm ighSW3nyXEKqbG0BaqGo2iCC/2f6Q9tD+hvNSOq8dBWuI2Xj4T5LgDYX+yqCRcIWon6e h1YxMdQNC6MHDKfmsdNv65A+e07omWtJS3oRV2fP423QbltQpcp8W8juKT/8tb5uNly4 T0qDhKumtsX5QghLRyaDeDE1zy+wzHQAztEo5YYcK7tH4n5ZU9zsaxRYrVrDu/WK5oOE 5+3ClBPVVWnkkPHHrRZAhrNVYMl+kIvGC/Ydkr1BmYIyCc4quFdm3XEc6dgrepBfbnlO 6zAg== X-Gm-Message-State: ALoCoQkhRofI3LevIX2G3ejw/3yBBW+mezxORGAxd8L9+AjCAbVjnMo+0k0HiAyN9HVi1KTUBwEM X-Received: by 10.140.165.76 with SMTP id l73mr85603227qhl.16.1426625640472; Tue, 17 Mar 2015 13:54:00 -0700 (PDT) Received: from [192.168.8.100] ([181.202.4.92]) by mx.google.com with ESMTPSA id 132sm10386555qhf.17.2015.03.17.13.53.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 13:53:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9136E9A8-2E8A-40FF-8BDE-E9289B2FDFFE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <40858890.46948.1426624784094.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Mar 2015 17:53:53 -0300 Message-Id: <5B76BC82-5987-4902-AF13-4E23217C131E@ve7jtb.com> References: <7B21E963-C247-4452-B9DF-4D370433511B@ve7jtb.com> <40858890.46948.1426624784094.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 20:54:06 -0000 --Apple-Mail=_9136E9A8-2E8A-40FF-8BDE-E9289B2FDFFE Content-Type: multipart/alternative; boundary="Apple-Mail=_5204C3F4-99C2-40C4-BFF6-76088672B352" --Apple-Mail=_5204C3F4-99C2-40C4-BFF6-76088672B352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com", and that potentially doesn't solve the security = issue if a client just passes on the scopes it receives in the error = response, the bad RS just adds a scope for the good RS. The client then potentially needs to understand the custom structures = scopes of every AS it might deal with. I think that would lead to lots of problems trying to make that a = pattern long term. At teh moment yes you can do it with a scope as = long as the client and AS both understand what is going on. We added "aud" as a separate parameter for PoP as the token format for = different RS might be different as well as the symmetric pop keys = needing to be encrypted with different keys. Yes we could have invented a special scope to carry the audience but a = separate parameter was much cleaner. I know some people have started using "aud" as a way to communicate the = resource when a scope applies to multiple RS but they may take different = token formats JWT vs opaque etc. Brian commented that the "aud" parameter may be useful beyond PoP so we = might want to think about documenting it in it's own mini spec, if I = understood him correctly. I think that may not be a bad idea as we are also planning on using it = in NAPPS. John B. > On Mar 17, 2015, at 5:39 PM, Bill Mills = wrote: >=20 > I don't think it's "overloading scope names" to use them that way. = The aud value(s) could as easily be carried in scope as anywhere. = Nothing says a scope can't be "https://foo.com", and that Foo.com = requires that scope to be present for a token to be accepted. I would = not make it foo.com-read-mail for example. >=20 > If it's more convenient to put it in aud I can accept that, but it's = the same functionality and can be implemented in scopes now. >=20 >=20 >=20 > On Tuesday, March 17, 2015 12:41 PM, John Bradley = wrote: >=20 >=20 > People have been overloading scope names to create implicit audience. = =20 >=20 > The problem is that clients need to know via some magic method that = you need to ask for scope "purple" to get write access to RS 2. >=20 > Having an explicit "aud" parameter gives clients a way to communicate = to the AS what RS they are asking for a token for.=20 >=20 > the security issue is that if a client discovers a API out via some = out of band mechanism the OAuth error code can tell the client go to AS = X and ask for Scope Y. =20 >=20 > Unfortunately without POP tokens or at-least passing the URI of the RS = to the AS via "aud", a bad RS could get a legitimate client to give it a = token that can be replayed at a legitimate RS. >=20 > This was one of the issues that Eran Hammer-Lahav was particularly = concerned about. =20 >=20 > I think I proposed a "aud" parameter to the token endpoint back then = as a alternative to requiring HMAC tokens, but that got lost in the = confusion at the time. >=20 > At that time though people were not yet thinking about interoperable = OAuth API, only relatively tightly bound clients that were = preconfigured for the API endpoints they were using. >=20 > In Health and other places we are starting to see standard clients = that discover API endpoints and configure themselves based on a users = Identity to use a arbitrary OAuth AS, moving into federation of AT. >=20 > That is one of the reasons POP will be important, as it prevents RS = from misusing federated tokens by presenting them at other RS. >=20 > The simplest thing to do is have the client say what RS it is trying = to access explicitly (The "aud" parameter), and including an audience in = the AT. to protect against malicious RS. >=20 > PoP is the step up that also protects against tokens being intercepted = and replayed by another client. >=20 > John B. >=20 >> On Mar 17, 2015, at 4:10 PM, Bill Mills > wrote: >>=20 >> This may have been hashed out already and I missed it, but "aud" just = becomes another kind of scope, correct? >>=20 >>=20 >>=20 >>=20 >> On Tuesday, March 17, 2015 8:50 AM, John Bradley > wrote: >>=20 >>=20 >> You could do that, but it is probably safer for the AS to know what = RS it can issue tokens for and refuse to issue a token for RS A to a = client asking for a token with RS X as the aud. >>=20 >> John B. >>> On Mar 16, 2015, at 8:27 PM, Dixie Baker = > = wrote: >>>=20 >>=20 >> The threat that RFC6819 4.6.4 describes is when a client obtains an = AT and then sends it to a counterfeit RS, which then uses the AT to = access resources from a legitimate RS, on the end-user's behalf. =20 >>=20 >> The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." =20 >>=20 >> As I read this, the suggestion is to have the client pass the URL of = the bad RS in the request to the AS (using the audience field). The AS = then would include that RS URL in the AT. Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request. =20 >>=20 >> -Dixie >>=20 >>=20 >>=20 >> Dixie B. Baker, Ph.D. >> Senior Partner >> Martin, Blanck and Associates >> Office (Redondo Beach, CA): 310-791-9671 >> Mobile: 310-279-2579 >>=20 >> On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >>=20 >>=20 >> Brian and I were talking about "aud" used as a parameter to the token = endpoint when using a code or refresh token to indicate what RS the = resulting AT will be used at. >>=20 >> Sending a audience in the AT wouldn't help prevent the attack being = discussed, though it may stop other sorts of attacks if the RS can tell = if a AT was issued for it or another RS. >>=20 >> In PoP having the AS check that you are sending the AT to the correct = RS is less important as the AT if stolen can't be used to replay against = the real AS. >>=20 >> Though depending on the app the bogus RS feeding the app the wrong = info may well be a problem as well. >>=20 >> John B. >>=20 >>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>>=20 >>=20 >> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>=20 >> POP on the contrary helps since the counterfeit RS, in order to send = a message to the legitimate RS, needs to produce a new digitally signed = message using the correct secret, which it doesn't know. >>=20 >> kind regards, >> Torsten. >>=20 >>=20 >>=20 >> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>=20 >>=20 >> Using the "aud" parameter makes sense to me. Good suggestion. >>=20 >> Authenticating the client to the RS would not address the counterfeit = RS threat.=20 >>=20 >> -Dixie >>=20 >> =20 >> Dixie B. Baker, Ph.D. >> Senior Partner >> Martin, Blanck and Associates >> Office (Redondo Beach, CA): 310-791-9671 >> Mobile: 310-279-2579 >>=20 >> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>=20 >>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help = identify the RS to whom the AT should be issued. It is useful but it's = mostly about getting format/content/etc of the AT correct for the RS = rather than it is about preventing possible AT leaks. >>>=20 >>> I do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.=20 >>>=20 >>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>=20 >>> It would be possible to have a small spec to define using "aud" with = bearer tokens, however that would be undefined behaviour at this point. >>>=20 >>> I don't know of any clients that would try to access a RS server and = then besed on the error response try and get a access token from the AS = specified in the error. >>>=20 >>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>=20 >>> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>=20 >>>> Hi Josh, >>>>=20 >>>> I'm not aware of a common practice to use such a parameter. The WG = is instead heading towards authenticated requests to the resource server = (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>=20 >>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>=20 >>>> kind regards, >>>> Torsten. >>>>=20 >>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>> Hi All, >>>>>=20 >>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>=20 >>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>=20 >>>>> https://auth-server/authorize ? >>>>> response_type=3Dcode& >>>>> client_id=3D123& >>>>> state=3D456& >>>>> scope=3Dread-all& >>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>=20 >>>>> (And if the authorization server saw a value it didn't like in the = final parameter, it would reject the request.) >>>>>=20 >>>>> This is obviously not appropriate in every authorization scenario, = but it is useful anytime there's a discovery process by which apps learn = about authorization servers from resource servers. Since it's something = of a common need, I wanted to see if there was any common practice in = how to name this parameter, or whether it's worth registering a standard = extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>=20 >>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Josh >>>>>=20 >>>>>=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 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_5204C3F4-99C2-40C4-BFF6-76088672B352 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes but it is custom.  People are inventing structured = scopes like "aud:https://foo.com", and that potentially doesn't solve the security = issue if a client just passes on the scopes it receives in the error = response, the bad RS just adds a scope for the good RS.
The client then potentially needs to = understand the custom structures scopes of every AS it might deal = with.

I think = that would lead to lots of problems trying to make that a pattern long = term.   At teh moment yes you can do it with a scope as long as the = client and AS both understand what is going on.


We = added "aud" as a separate parameter for PoP as the token format for = different RS might be different as well as the symmetric  pop keys = needing to be encrypted with different keys.
Yes we = could have invented a special scope to carry the audience but a separate = parameter was much cleaner.

I know some people have started using "aud" as a way to = communicate the resource when a scope applies to multiple RS but they = may take different token formats JWT vs opaque etc.

Brian commented that the = "aud" parameter may be useful beyond PoP so we might want to think about = documenting it in it's own mini spec, if I understood him = correctly.

I = think that may not be a bad idea as we are also planning on using it in = NAPPS.

John = B.

On Mar 17, 2015, at 5:39 PM, = Bill Mills <wmills_92105@yahoo.com> wrote:

I don't think it's "overloading scope names" to use them = that way.  The aud value(s) could as easily be carried in scope as = anywhere.  Nothing says a scope can't be "https://foo.com", and that Foo.com requires that scope to be present for a token to = be accepted.  I would not make it foo.com-read-mail for example.

If it's more = convenient to put it in aud I can accept that, but it's the same = functionality and can be implemented in scopes now.



=
On Tuesday, = March 17, 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


=
People have been overloading scope names to create implicit = audience.   

The problem = is that clients need to know via some magic method that you need to ask = for scope "purple" to get write access to RS 2.

Having an = explicit "aud" parameter gives clients a way to communicate to the AS = what RS they are asking for a token for. 

the security = issue is that if a client discovers a API out via some out of band = mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y.  

Unfortunately = without POP tokens or at-least passing the URI of the RS to the AS via = "aud", a bad RS could get a legitimate client to give it a token that = can be replayed at a legitimate RS.

This was one of the issues that Eran = Hammer-Lahav was particularly concerned about.  

I think I = proposed a "aud" parameter to the token endpoint back then as a = alternative to requiring HMAC tokens, but that got lost in the confusion = at the time.

At that time = though people were not yet thinking about interoperable OAuth API, =  only relatively tightly bound clients that were preconfigured for = the API endpoints they were using.

In Health and other places we are starting to = see standard clients that discover API endpoints and configure = themselves based on a users Identity to use a arbitrary OAuth AS, moving = into federation of AT.

That is one of the reasons POP will be = important, as it prevents RS from misusing federated tokens by = presenting them at other RS.

The simplest thing to do is have the client say = what RS it is trying to access explicitly (The "aud" parameter), and = including an audience in the AT.  to protect against malicious = RS.

PoP is the = step up that also protects against tokens being intercepted and replayed = by another client.

John = B.

On Mar 17, 2015, at 4:10 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

This may have been hashed out already and I = missed it, but "aud" just becomes another kind of scope, = correct?




On = Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
You could do that, but it is probably safer for = the AS to know what RS it can issue tokens for and refuse to issue a = token for RS A to a client asking for a token with RS X as the = aud.

John B.
On Mar 16, 2015, at 8:27 PM, = Dixie Baker <Dixie.Baker@martin-blanck.co= m> wrote:

The threat that RFC6819 4.6.4 describes = is when a client obtains an AT and then sends it to a counterfeit RS, = which then uses the AT to access resources from a legitimate RS, on the = end-user's behalf.  

The suggested = countermeasure is a bit difficult to interpret:  "Associate the = endpoint URL of the resource server the client talked to with the access = token (e.g., in an audience field) and validate the association at a = legitimate resource server.  The endpoint URL validation policy may = be strict (exact match) or more relaxed (e.g., same host).  This = would require telling the authorization server about the resource server = endpoint URL in the authorization process."  

As I read = this, the suggestion is to have the client pass the URL of the bad RS in = the request to the AS (using the audience field).  The AS then = would include that RS URL in the AT.  Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request.  

-Dixie



Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 11:39 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Brian and I were talking about "aud" = used as a parameter to the token endpoint when using a code or refresh = token to indicate what RS the resulting AT will be used at.

Sending a = audience in the AT wouldn't help prevent the attack being discussed, =  though it may stop other sorts of attacks if the RS can tell if a = AT was issued for it or another RS.

In PoP having the AS check that you are sending = the AT to the correct RS is less important as the AT if stolen can't be = used to replay against the real AS.

Though depending on the app the bogus RS feeding = the app the wrong info may well be a problem as well.

John = B.

On = Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

I don't think putting an aud into an AT will = help to prevent counterfeit RSs (as long as the aud is nit directly = derived from the original URL used by the client to invoke the = counterfeit RS. as long as the aud is a symbolic name of any kind, the = counterfeit RS will accept ATs for the legitimate RS and just (ab)use = it.

POP on the = contrary helps since the counterfeit RS, in order to send a message to = the legitimate RS, needs to produce a new digitally signed message using = the correct secret, which it doesn't know.

kind = regards,
Torsten.



Am = 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.co= m>:

Using the "aud" parameter makes sense to me. =  Good suggestion.

Authenticating = the client to the RS would not address the counterfeit RS = threat. 

-Dixie

 
Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 6:43 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

We've used "aud" (optionally) = with OAuth 2 and bearer tokens to help identify the RS to whom the AT = should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I= do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:
In POP key = distribution we do introduce a "audiance" parameter to the = token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distr= ibution-01#section-3.1

It would be = possible to have a small spec to define using "aud" with bearer tokens, = however that would be undefined behaviour at this point.

I don't know = of any clients that would try to access a RS server and then besed on = the error response try and get a access token from the AS specified in = the error.

In POP we are = trying to both protect agains that attack and more common ones like = doing a MiM to intercept the AT or the RS being hacked and leaking the = token.

Using "aud" = with bearer tokens would be useful, but probably won't stop the majority = of possible AT leaks.

John = B.


On Mar 15, 2015, at 2:18 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.i= etf.org/html/rfc6819#section-5.4.2).

Please take a look onto http= ://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access = Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation = would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?<= /div>
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&= amp;
resource_server_that_told_me_to_authorize_here=3D<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv3782689420" = target=3D"_blank" = href=3D"https://attacker.com/">https://attacker.com

(And if the authorization server = saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate = in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.x= html . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? = The name I used in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


=



=

= --Apple-Mail=_5204C3F4-99C2-40C4-BFF6-76088672B352-- --Apple-Mail=_9136E9A8-2E8A-40FF-8BDE-E9289B2FDFFE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTcyMDUzNTRaMCMGCSqGSIb3DQEJBDEWBBTrpRsBmBmfncA4YDxC6uZr hTy+jDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBTRRuIkz5gJHnIiM2lmm014JrUN/xAHYERYjBg5eORsUXC5wTx5AAi aWfVn6rT0SgTsv6AzQ/eGXEZOGUIxoxRFSO+crX8FucmCwjFsRpCA5S22TkT6yYtEe+P7/8mF1sF xriO0nwA95E0PbiZzialhycR21+9jYycMFu8RZMavxvQwvFN+2ESEmHkkPdSBzXpy9B8TnUbID/p yEEpoUkCBCFom/YGL2smVyu/lemfYpgD7gYZE50Lrm/oYF37WexOofFM3dCQyXILmlZsAhQUfa1h PiIILlRJQCUAwTu+ZDaN9q7aDzsAlXinwuy96C+bWcjc9K2hkRLF2+ClGas+AAAAAAAA --Apple-Mail=_9136E9A8-2E8A-40FF-8BDE-E9289B2FDFFE-- From nobody Tue Mar 17 14:00:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E491A88EC for ; Tue, 17 Mar 2015 14:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 JMHX5flvBJyk for ; Tue, 17 Mar 2015 14:00:20 -0700 (PDT) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EE01A88E7 for ; Tue, 17 Mar 2015 14:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426626019; bh=pVAzMDS4xkmDwX+E/DLuGQv/AxswQqD6GHzY+feQXuE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=tvP/gdmcTq8k31/ZTdPkRL4Wkw9CZpM1syn/7NskDzMr/XRNG5h8FBig0RQ/gsY0Vre9Fb8T9lT5jpcZOr3bNeboijQia4Ifh4VzP2JLg/B7oBwqhzcgpjcbZw92owtAQGlM/exroUqd6rAq4Y1VMF0Nl2haZuVwFvIyU5xdu4viez6hZUc16WT5x+RHqt5ID6d5/U8jKl/s3ebg3KCBG904/LmPLZM7zL09KuLNyd4UDN0wnuOxghHY+oN6LtTNfR4To1K4mFpSFmCNlbNckkUHHbUfU67vXdOCndcimNVCbNWlK57aADaBslaobbQvuA7ZL1gta6y5V0iRHskDRw== Received: from [98.139.215.141] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:00:19 -0000 Received: from [98.139.212.199] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:00:19 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:00:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 73450.38560.bm@omp1008.mail.bf1.yahoo.com X-YMail-OSG: WXLyzMIVM1nJC8pMa.w1sbt2TyPuYjVSBUsoCnL.Foq4_gB0zXRLkhYyM_XQuWC PYrKvch0s13Hz82e0o7GBrmNt688fL8RMSk7FlNudLnyJe_ZcwilVEgcmOw_7H.eDm1nw1IkLzh. lZWJHz2nQl7JxK6hQ2b_U4wdjHqWexuL_ItJw15UxhQ0_7diS3x0p34dhVgo.RDSsx2OIU254deK wgstJcOEJVCbI79V9UMfhgbo9z63HNR9Clrm_0_sj41FNZCnB.PZR1QOT0on_hJurFc9CtxPcGOl XgOqw2A5G644j2HQ31hZWfREfZ0CcnKmvjh_EA_sKwLEoFSKEvtg9Rw5U1OhAUiSBYYU2CeHpgd5 vOTJydncyYZzubESPn_uBVNwkQzuMyj3lk19jsi2WMWKEd6Ya2tMTxW0Hr9ZC_mMm9zdeqg0ZYMT 3eCY4ljrVG6BkHkhl221Nes6kCnjqDB_UHo9ucIzTWbknat75vMsFqYBvTK8WJDoBf6j7u6gtxiN oD2C4OGCkzOgF8g4VGm1oZ8olFW8YK7m58eF.1LmuzxwM9Nh19J996AqoGgEsWTzXPt.BLhhYuZf Ff3Lv4VpV Received: by 66.196.81.116; Tue, 17 Mar 2015 21:00:17 +0000 Date: Tue, 17 Mar 2015 21:00:17 +0000 (UTC) From: Bill Mills To: John Bradley Message-ID: <1226254101.44049.1426626017191.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <5B76BC82-5987-4902-AF13-4E23217C131E@ve7jtb.com> References: <5B76BC82-5987-4902-AF13-4E23217C131E@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_44046_1029325470.1426626017161" Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:00:24 -0000 ------=_Part_44046_1029325470.1426626017161 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Yes but it is custom. =C2=A0People are inventing structured scopes like "a= ud:https://foo.com", and that potentially doesn't solve the security issue = if a client just passes on the scopes it receives in the error response, th= e bad RS just adds a scope for the good RS." This isn't solved by "aud", it is solved by OAuth 1.0a though.... =C2=A0 On Tuesday, March 17, 2015 1:54 PM, John Bradley w= rote: =20 Yes but it is custom. =C2=A0People are inventing structured scopes like "a= ud:https://foo.com", and that potentially doesn't solve the security issue = if a client just passes on the scopes it receives in the error response, th= e bad RS just adds a scope for the good RS. The client then potentially needs to understand the custom structures scope= s of every AS it might deal with. I think that would lead to lots of problems trying to make that a pattern l= ong term. =C2=A0 At teh moment yes you can do it with a scope as long as th= e client and AS both understand what is going on. We added "aud" as a separate parameter for PoP as the token format for diff= erent RS might be different as well as the symmetric =C2=A0pop keys needing= to be encrypted with different keys.Yes we could have invented a special s= cope to carry the audience but a separate parameter was much cleaner. I know some people have started using "aud" as a way to communicate the res= ource when a scope applies to multiple RS but they may take different token= formats JWT vs opaque etc. Brian commented that the "aud" parameter may be useful beyond PoP so we mig= ht want to think about documenting it in it's own mini spec, if I understoo= d him correctly. I think that may not be a bad idea as we are also planning on using it in N= APPS. John B. On Mar 17, 2015, at 5:39 PM, Bill Mills wrote: I don't think it's "overloading scope names" to use them that way. =C2=A0Th= e aud value(s) could as easily be carried in scope as anywhere. =C2=A0Nothi= ng says a scope can't be "https://foo.com", and that Foo.com requires that = scope to be present for a token to be accepted. =C2=A0I would not make it f= oo.com-read-mail for example. If it's more convenient to put it in aud I can accept that, but it's the sa= me functionality and can be implemented in scopes now.=20 On Tuesday, March 17, 2015 12:41 PM, John Bradley = wrote: =20 People have been overloading scope names to create implicit audience. =C2= =A0=C2=A0 The problem is that clients need to know via some magic method that you nee= d to ask for scope "purple" to get write access to RS 2. Having an explicit "aud" parameter gives clients a way to communicate to th= e AS what RS they are asking for a token for.=C2=A0 the security issue is that if a client discovers a API out via some out of = band mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y. =C2=A0 Unfortunately without POP tokens or at-least passing the URI of the RS to t= he AS via "aud", a bad RS could get a legitimate client to give it a token = that can be replayed at a legitimate RS. This was one of the issues that Eran Hammer-Lahav was particularly concerne= d about. =C2=A0 I think I proposed a "aud" parameter to the token endpoint back then as a a= lternative to requiring HMAC tokens, but that got lost in the confusion at = the time. At that time though people were not yet thinking about interoperable OAuth = API, =C2=A0only relatively tightly bound clients that were preconfigured fo= r the API endpoints they were using. In Health and other places we are starting to see standard clients that dis= cover API endpoints and configure themselves based on a users Identity to u= se a arbitrary OAuth AS, moving into federation of AT. That is one of the reasons POP will be important, as it prevents RS from mi= susing federated tokens by presenting them at other RS. The simplest thing to do is have the client say what RS it is trying to acc= ess explicitly (The "aud" parameter), and including an audience in the AT. = =C2=A0to protect against malicious RS. PoP is the step up that also protects against tokens being intercepted and = replayed by another client. John B. On Mar 17, 2015, at 4:10 PM, Bill Mills wrote: This may have been hashed out already and I missed it, but "aud" just becom= es another kind of scope, correct? =20 On Tuesday, March 17, 2015 8:50 AM, John Bradley w= rote: =20 You could do that, but it is probably safer for the AS to know what RS it = can issue tokens for and refuse to issue a token for RS A to a client askin= g for a token with RS X as the aud. John B. On Mar 16, 2015, at 8:27 PM, Dixie Baker wr= ote: The threat that RFC6819 4.6.4 describes is when a client obtains an AT and = then sends it to a counterfeit RS, which then uses the AT to access resourc= es from a legitimate RS, on the end-user's behalf. =C2=A0 The suggested countermeasure is a bit difficult to interpret: =C2=A0"Associ= ate the endpoint URL of the resource server the client talked to with the a= ccess token (e.g., in an audience field) and validate the association at a = legitimate resource server. =C2=A0The endpoint URL validation policy may be= strict (exact match) or more relaxed (e.g., same host). =C2=A0This would r= equire telling the authorization server about the resource server endpoint = URL in the authorization process." =C2=A0 As I read this, the suggestion is to have the client pass the URL of the ba= d RS in the request to the AS (using the audience field). =C2=A0The AS then= would include that RS URL in the AT. =C2=A0Then, when the client passes th= e AT to the bad RS, and it passes it on to the good RS, the good RS will ch= eck the audience field, compare that URL with its own, and refuse the reque= st. =C2=A0 -Dixie Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 11:39 AM, John Bradley wrote: Brian and I were talking about "aud" used as a parameter to the token endpo= int when using a code or refresh token to indicate what RS the resulting AT= will be used at. Sending a audience in the AT wouldn't help prevent the attack being discuss= ed, =C2=A0though it may stop other sorts of attacks if the RS can tell if a= AT was issued for it or another RS. In PoP having the AS check that you are sending the AT to the correct RS is= less important as the AT if stolen can't be used to replay against the rea= l AS. Though depending on the app the bogus RS feeding the app the wrong info may= well be a problem as well. John B. On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = wrote: I don't think putting an aud into an AT will help to prevent counterfeit RS= s (as long as the aud is nit directly derived from the original URL used by= the client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate RS = and just (ab)use it. POP on the contrary helps since the counterfeit RS, in order to send a mess= age to the legitimate RS, needs to produce a new digitally signed message u= sing the correct secret, which it doesn't know. kind regards,Torsten. Am 16.03.2015 um 17:40 schrieb Dixie Baker : Using the "aud" parameter makes sense to me. =C2=A0Good suggestion. Authenticating the client to the RS would not address the counterfeit RS th= reat.=C2=A0 -Dixie =C2=A0 Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 6:43 AM, Brian Campbell wr= ote: We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identi= fy the RS to whom the AT should be issued. It is useful but it's mostly abo= ut getting format/content/etc of the AT correct for the RS rather than it i= s about preventing possible AT leaks. I do think an "aud(iance)" parameter at both token and authorization endpoi= nts would have utility beyond the POP work. So defining it independently mi= ght make sense.=20 On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: In POP key distribution we do introduce a "audiance" parameter to the token= _endpoint.=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distri= bution-01#section-3.1 It would be possible to have a small spec to define using "aud" with bearer= tokens, however that would be undefined behaviour at this point. I don't know of any clients that would try to access a RS server and then b= esed on the error response try and get a access token from the AS specified= in the error. In POP we are trying to both protect agains that attack and more common one= s like doing a MiM to intercept the AT or the RS being hacked and leaking t= he token. Using "aud" with bearer tokens would be useful, but probably won't stop the= majority of possible AT leaks. John B. On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = wrote: Hi Josh, =20 I'm not aware of a common practice to use such a parameter. The WG is inst= ead heading towards authenticated requests to the resource server (see http= s://tools.ietf.org/html/rfc6819#section-5.4.2).=20 =20 Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-ar= chitecture and further drafts on this topic. =20 kind regards, Torsten. =20 Am 03.03.2015 um 18:27 schrieb Josh Mandel: =20 Hi All,=20 In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource = Server"), RFC6819 describes a threat where a counterfeit resource server tr= icks a client into obtaining and sharing an access token from a legitimate = authorization server. One of the proposed mitigations involves: "telling th= e authorization server about the resource server endpoint URL in the author= ization process."=20 In other words, this mitigation would ask the client to pass an additiona= l parameter when redirecting to the Authorization server's "authorize" URL,= effectively something like:=20 https://auth-server/authorize? response_type=3Dcode& client_id=3D123& st= ate=3D456& scope=3Dread-all& redirect_uri=3Dhttps://app-server/after-auth& resourc= e_server_that_told_me_to_authorize_here=3Dhttps://attacker.com =20 (And if the authorization server saw a value it didn't like in the final = parameter, it would reject the request.)=20 This is obviously not appropriate in every authorization scenario, but it= is useful anytime there's a discovery process by which apps learn about au= thorization servers from resource servers. Since it's something of a common= need, I wanted to see if there was any common practice in how to name this= parameter, or whether it's worth registering a standard extension at=C2=A0= http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (= I don't see one there now -- possibly I'm just missing it.)=20 If so, what should it be called? The name I used in the example above is = a bit verbose :-)=20 Best,=20 =C2=A0 Josh =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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 ------=_Part_44046_1029325470.1426626017161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"Yes but it is cust= om.  People are inventing structured scopes like "aud:https://<= a rel=3D"nofollow" shape=3D"rect" class=3D"" target=3D"_blank" href=3D"http= ://foo.com/" style=3D"color: rgb(25, 106, 212); font-family: 'Helvetica Neu= e', 'Segoe UI', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 1= 3px; background-color: rgb(255, 255, 255);">foo.com", and that potentially doesn't solve the security issue if a client ju= st passes on the scopes it receives in the error response, the bad RS just = adds a scope for the good RS."
This isn't solved by "aud", it = is solved by OAuth 1.0a though....
 



On Tuesday, March 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:


Yes but it is custom.  People are inventing s= tructured scopes like "aud:https://foo.com",= and that potentially doesn't solve the security issue if a client just pas= ses on the scopes it receives in the error response, the bad RS just adds a= scope for the good RS.

The client then pote= ntially needs to understand the custom structures scopes of every AS it mig= ht deal with.

I think that would lead = to lots of problems trying to make that a pattern long term.   At teh = moment yes you can do it with a scope as long as the client and AS both und= erstand what is going on.


We added = "aud" as a separate parameter for PoP as the token format for different RS = might be different as well as the symmetric  pop keys needing to be en= crypted with different keys.
Yes we could= have invented a special scope to carry the audience but a separate paramet= er was much cleaner.

I know some peopl= e have started using "aud" as a way to communicate the resource when a scop= e applies to multiple RS but they may take different token formats JWT vs o= paque etc.

Brian commented that the "a= ud" parameter may be useful beyond PoP so we might want to think about docu= menting it in it's own mini spec, if I understood him correctly.

I think that may not be a bad idea as we are als= o planning on using it in NAPPS.

John = B.

On Mar 17, 2015, at 5:39 PM, Bill Mi= lls <wmills_92105@yahoo.com> wrote:

I don't thi= nk it's "overloading scope names" to use them that way.  The aud value= (s) could as easily be carried in scope as anywhere.  Nothing says a s= cope can't be "https://foo.com", and that <= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv2022977117" target=3D"_blank"= href=3D"http://foo.com/">Foo.com requires that scope to be present for= a token to be accepted.  I would not make it foo.com-read-mail for example.

<= /div>
If it's more convenient to put it in aud I = can accept that, but it's the same functionality and can be implemented in = scopes now.



= On Tuesday, March= 17, 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


People have been overloading scope na= mes to create implicit audience.   
<= br clear=3D"none" class=3D"yiv2022977117">
The problem is that clients need to know via some magic method that you n= eed to ask for scope "purple" to get write access to RS 2.

Having an explicit "aud" parameter gives clients a way to co= mmunicate to the AS what RS they are asking for a token for. 

the secur= ity issue is that if a client discovers a API out via some out of band mech= anism the OAuth error code can tell the client go to AS X and ask for Scope= Y.  

Unfortunately without POP t= okens or at-least passing the URI of the RS to the AS via "aud", a bad RS c= ould get a legitimate client to give it a token that can be replayed at a l= egitimate RS.

This was one of the issu= es that Eran Hammer-Lahav was particularly concerned about.  

=
I think I proposed a "aud" parameter to the to= ken endpoint back then as a alternative to requiring HMAC tokens, but that = got lost in the confusion at the time.
At that time though people were not yet thinking about interoperable OAuth= API,  only relatively tightly bound clients that were preconfigured f= or the API endpoints they were using.
= In Health and other places we are starting to see standard clients that dis= cover API endpoints and configure themselves based on a users Identity to u= se a arbitrary OAuth AS, moving into federation of AT.

That is one of the reasons POP will be important, as it = prevents RS from misusing federated tokens by presenting them at other RS.<= /div>

The simplest thing to do is have the c= lient say what RS it is trying to access explicitly (The "aud" parameter), = and including an audience in the AT.  to protect against malicious RS.=

PoP is the step up that also protects= against tokens being intercepted and replayed by another client.

<= div class=3D"yiv2022977117">John B.

On Mar 17, 2015, at 4:10 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

This may have been hashed out already and I mis= sed it, but "aud" just becomes another kind of scope, correct?
=


<= div class=3D"yiv2022977117qtdSeparateBR">

On Tuesday, Mar= ch 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


You coul= d do that, but it is probably safer for the AS to know what RS it can issue= tokens for and refuse to issue a token for RS A to a client asking for a t= oken with RS X as the aud.

John B.
On Mar = 16, 2015, at 8:27 PM, Dixie Baker <Dixie.Baker@mar= tin-blanck.com> wrote:

The threat that RFC6819 4.6.4 describes= is when a client obtains an AT and then sends it to a counterfeit RS, whic= h then uses the AT to access resources from a legitimate RS, on the end-use= r's behalf.  

The suggested countermeas= ure is a bit difficult to interpret:  "Associate the endpoint URL of t= he resource server the client talked to with the access token (e.g., in an = audience field) and validate the association at a legitimate resource serve= r.  The endpoint URL validation policy may be strict (exact match) or = more relaxed (e.g., same host).  This would require telling the author= ization server about the resource server endpoint URL in the authorization = process."  

As I read this, the s= uggestion is to have the client pass the URL of the bad RS in the request t= o the AS (using the audience field).  The AS then would include that R= S URL in the AT.  Then, when the client passes the AT to the bad RS, a= nd it passes it on to the good RS, the good RS will check the audience fiel= d, compare that URL with its own, and refuse the request.  

-Dixie


<= div class=3D"yiv2022977117">
Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 11:39 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:

<= div class=3D"yiv2022977117" style=3D"word-wrap:break-word;">Brian and I wer= e talking about "aud" used as a parameter to the token endpoint when using = a code or refresh token to indicate what RS the resulting AT will be used a= t.

<= /div>
Sending a audience in the AT wouldn't hel= p prevent the attack being discussed,  though it may stop other sorts = of attacks if the RS can tell if a AT was issued for it or another RS.

In PoP having the AS check that you are se= nding the AT to the correct RS is less important as the AT if stolen can't = be used to replay against the real AS.
Though depending on the app the bogus RS feeding the app the wrong info ma= y well be a problem as well.

John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodd= erstedt <torsten@lodderstedt.net> wrote:

I don't= think putting an aud into an AT will help to prevent counterfeit RSs (as l= ong as the aud is nit directly derived from the original URL used by the cl= ient to invoke the counterfeit RS. as long as the aud is a symbolic name of= any kind, the counterfeit RS will accept ATs for the legitimate RS and jus= t (ab)use it.

POP on the contrary help= s since the counterfeit RS, in order to send a message to the legitimate RS= , needs to produce a new digitally signed message using the correct secret,= which it doesn't know.

kind regards,<= /div>
Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "au= d" parameter makes sense to me.  Good suggestion.

Authenticating the client to the RS would not address the counte= rfeit RS threat. 

-Dixie

=
 
Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv2022977117" ymailto=3D"mailto= :bcampbell@pingidentity.com" target=3D"_blank" href=3D"mailto:bcampbell@pin= gidentity.com">bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 and bea= rer tokens to help identify the RS to whom the AT should be issued. It is u= seful but it's mostly about getting format/content/etc of the AT correct fo= r the RS rather than it is about preventing possible AT leaks.

I do think an "aud(iance)" parameter at both token and authorization en= dpoints would have utility beyond the POP work. So defining it independentl= y might make sense.

On Sun, Mar 15, 2015 at 11:34 AM,= John Bradley <ve7jtb@ve7jtb.com= > wrote:
In POP key distribution we do introduce a "audiance" p= arameter to the token_endpoint. https://tools.ietf.or= g/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1

It would be possible to have a small spec to define u= sing "aud" with bearer tokens, however that would be undefined behaviour at= this point.

I don't know of any clien= ts that would try to access a RS server and then besed on the error respons= e try and get a access token from the AS specified in the error.

In POP we are trying to both protect agains that= attack and more common ones like doing a MiM to intercept the AT or the RS= being hacked and leaking the token.

U= sing "aud" with bearer tokens would be useful, but probably won't stop the = majority of possible AT leaks.

John B= .


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt &= lt;torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Toke= n Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would = ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_= server_that_told_me_to_authorize_here=3Dht= tps://attacker.com

(And if the authorization server saw a= value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in e= very authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-p= arameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The n= ame I used in the example above is a bit verbose :-)

Best,

  Josh


________________________________________=
_______
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org=
/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oau= th
<= br clear=3D"none" class=3D"yiv2022977117">

_________________________________________= ______
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth



<= /div>

=
<= /div>

------=_Part_44046_1029325470.1426626017161-- From nobody Tue Mar 17 14:12:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619441A88E7 for ; Tue, 17 Mar 2015 14:12:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 RksGhXw_HT4R for ; Tue, 17 Mar 2015 14:12:03 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (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 9976D1A88DC for ; Tue, 17 Mar 2015 14:12:02 -0700 (PDT) Received: by qgh62 with SMTP id 62so20799466qgh.1 for ; Tue, 17 Mar 2015 14:12:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ImIaw0Fs4Df1yy6/9T3bUK7KFSKImV1Sr7RcT3woOxo=; b=ZT5Ocje8J6awcZPwmkrdNrBT3KsULGeEXVT+0mIrZu5TzqcfdSD35K5wX0V8iVUlkI /pPpmh8PqhVLrNpBbVjMbpLQtyw64fUD7xUfeYVX/qNJ1lWbLM4pz0+ieRGrCIoaQhxB DZu9NC8Z/4mJyx9XOJPgvqqsaAIJ9Ur//JZ+BtaBfvDht+qTzO8ACVT8+0Px1aSJs8z/ OAP2T57mPqPoGMyE94hJLTh7TTcP/Uawzh3mGKZKib/uh+66LzxfupvvMayX7gjDQX9I 1fgDn2Enosi0A73a5KQvrofVTUzckP9IQEzn/wt8MfOvsVXtNvMgWmNMBJL6Z4nnPoLI hMIw== X-Gm-Message-State: ALoCoQnaabsEEatuuu8cSwP4wzuf821A+WG+k+2butIPCAojfIUbGtnLAhnQWLZK7BGjx5cjTgqN X-Received: by 10.140.202.17 with SMTP id x17mr87974225qha.50.1426626721642; Tue, 17 Mar 2015 14:12:01 -0700 (PDT) Received: from [192.168.8.100] ([181.202.4.92]) by mx.google.com with ESMTPSA id s7sm10496013qgd.4.2015.03.17.14.11.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 14:12:00 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A6E654A3-8441-4596-B4D8-D7F68D0B3F50"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <1226254101.44049.1426626017191.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Mar 2015 18:11:56 -0300 Message-Id: References: <5B76BC82-5987-4902-AF13-4E23217C131E@ve7jtb.com> <1226254101.44049.1426626017191.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:12:08 -0000 --Apple-Mail=_A6E654A3-8441-4596-B4D8-D7F68D0B3F50 Content-Type: multipart/alternative; boundary="Apple-Mail=_18E967A2-3846-4B1A-85E5-260255033BB1" --Apple-Mail=_18E967A2-3846-4B1A-85E5-260255033BB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Or by OAuth 2 PoP. =20 > On Mar 17, 2015, at 6:00 PM, Bill Mills = wrote: >=20 > "Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS." >=20 > This isn't solved by "aud", it is solved by OAuth 1.0a though.... > =20 >=20 >=20 >=20 > On Tuesday, March 17, 2015 1:54 PM, John Bradley = wrote: >=20 >=20 > Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS. >=20 > The client then potentially needs to understand the custom structures = scopes of every AS it might deal with. >=20 > I think that would lead to lots of problems trying to make that a = pattern long term. At teh moment yes you can do it with a scope as = long as the client and AS both understand what is going on. >=20 >=20 > We added "aud" as a separate parameter for PoP as the token format for = different RS might be different as well as the symmetric pop keys = needing to be encrypted with different keys. > Yes we could have invented a special scope to carry the audience but a = separate parameter was much cleaner. >=20 > I know some people have started using "aud" as a way to communicate = the resource when a scope applies to multiple RS but they may take = different token formats JWT vs opaque etc. >=20 > Brian commented that the "aud" parameter may be useful beyond PoP so = we might want to think about documenting it in it's own mini spec, if I = understood him correctly. >=20 > I think that may not be a bad idea as we are also planning on using it = in NAPPS. >=20 > John B. >=20 >> On Mar 17, 2015, at 5:39 PM, Bill Mills > wrote: >>=20 >> I don't think it's "overloading scope names" to use them that way. = The aud value(s) could as easily be carried in scope as anywhere. = Nothing says a scope can't be "https://foo.com ", and = that Foo.com requires that scope to be present for a = token to be accepted. I would not make it foo.com = -read-mail for example. >>=20 >> If it's more convenient to put it in aud I can accept that, but it's = the same functionality and can be implemented in scopes now. >>=20 >>=20 >>=20 >> On Tuesday, March 17, 2015 12:41 PM, John Bradley > wrote: >>=20 >>=20 >> People have been overloading scope names to create implicit audience. = =20 >>=20 >> The problem is that clients need to know via some magic method that = you need to ask for scope "purple" to get write access to RS 2. >>=20 >> Having an explicit "aud" parameter gives clients a way to communicate = to the AS what RS they are asking for a token for.=20 >>=20 >> the security issue is that if a client discovers a API out via some = out of band mechanism the OAuth error code can tell the client go to AS = X and ask for Scope Y. =20 >>=20 >> Unfortunately without POP tokens or at-least passing the URI of the = RS to the AS via "aud", a bad RS could get a legitimate client to give = it a token that can be replayed at a legitimate RS. >>=20 >> This was one of the issues that Eran Hammer-Lahav was particularly = concerned about. =20 >>=20 >> I think I proposed a "aud" parameter to the token endpoint back then = as a alternative to requiring HMAC tokens, but that got lost in the = confusion at the time. >>=20 >> At that time though people were not yet thinking about interoperable = OAuth API, only relatively tightly bound clients that were = preconfigured for the API endpoints they were using. >>=20 >> In Health and other places we are starting to see standard clients = that discover API endpoints and configure themselves based on a users = Identity to use a arbitrary OAuth AS, moving into federation of AT. >>=20 >> That is one of the reasons POP will be important, as it prevents RS = from misusing federated tokens by presenting them at other RS. >>=20 >> The simplest thing to do is have the client say what RS it is trying = to access explicitly (The "aud" parameter), and including an audience in = the AT. to protect against malicious RS. >>=20 >> PoP is the step up that also protects against tokens being = intercepted and replayed by another client. >>=20 >> John B. >>=20 >>> On Mar 17, 2015, at 4:10 PM, Bill Mills > wrote: >>>=20 >>> This may have been hashed out already and I missed it, but "aud" = just becomes another kind of scope, correct? >>>=20 >>>=20 >>>=20 >>>=20 >>> On Tuesday, March 17, 2015 8:50 AM, John Bradley > wrote: >>>=20 >>>=20 >>> You could do that, but it is probably safer for the AS to know what = RS it can issue tokens for and refuse to issue a token for RS A to a = client asking for a token with RS X as the aud. >>>=20 >>> John B. >>>> On Mar 16, 2015, at 8:27 PM, Dixie Baker = > = wrote: >>>>=20 >>>=20 >>> The threat that RFC6819 4.6.4 describes is when a client obtains an = AT and then sends it to a counterfeit RS, which then uses the AT to = access resources from a legitimate RS, on the end-user's behalf. =20 >>>=20 >>> The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." =20 >>>=20 >>> As I read this, the suggestion is to have the client pass the URL of = the bad RS in the request to the AS (using the audience field). The AS = then would include that RS URL in the AT. Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request. =20 >>>=20 >>> -Dixie >>>=20 >>>=20 >>>=20 >>> Dixie B. Baker, Ph.D. >>> Senior Partner >>> Martin, Blanck and Associates >>> Office (Redondo Beach, CA): 310-791-9671 >>> Mobile: 310-279-2579 >>>=20 >>> On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >>>=20 >>>=20 >>> Brian and I were talking about "aud" used as a parameter to the = token endpoint when using a code or refresh token to indicate what RS = the resulting AT will be used at. >>>=20 >>> Sending a audience in the AT wouldn't help prevent the attack being = discussed, though it may stop other sorts of attacks if the RS can tell = if a AT was issued for it or another RS. >>>=20 >>> In PoP having the AS check that you are sending the AT to the = correct RS is less important as the AT if stolen can't be used to replay = against the real AS. >>>=20 >>> Though depending on the app the bogus RS feeding the app the wrong = info may well be a problem as well. >>>=20 >>> John B. >>>=20 >>>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>>>=20 >>>=20 >>> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>>=20 >>> POP on the contrary helps since the counterfeit RS, in order to send = a message to the legitimate RS, needs to produce a new digitally signed = message using the correct secret, which it doesn't know. >>>=20 >>> kind regards, >>> Torsten. >>>=20 >>>=20 >>>=20 >>> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>>=20 >>>=20 >>> Using the "aud" parameter makes sense to me. Good suggestion. >>>=20 >>> Authenticating the client to the RS would not address the = counterfeit RS threat.=20 >>>=20 >>> -Dixie >>>=20 >>> =20 >>> Dixie B. Baker, Ph.D. >>> Senior Partner >>> Martin, Blanck and Associates >>> Office (Redondo Beach, CA): 310-791-9671 >>> Mobile: 310-279-2579 >>>=20 >>> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>>=20 >>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to = help identify the RS to whom the AT should be issued. It is useful but = it's mostly about getting format/content/etc of the AT correct for the = RS rather than it is about preventing possible AT leaks. >>>>=20 >>>> I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So = defining it independently might make sense.=20 >>>>=20 >>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>>=20 >>>> It would be possible to have a small spec to define using "aud" = with bearer tokens, however that would be undefined behaviour at this = point. >>>>=20 >>>> I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the = AS specified in the error. >>>>=20 >>>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>>=20 >>>> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>>=20 >>>>> Hi Josh, >>>>>=20 >>>>> I'm not aware of a common practice to use such a parameter. The WG = is instead heading towards authenticated requests to the resource server = (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>>=20 >>>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>>=20 >>>>> kind regards, >>>>> Torsten. >>>>>=20 >>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>> Hi All, >>>>>>=20 >>>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>>=20 >>>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>>=20 >>>>>> https://auth-server/authorize ? >>>>>> response_type=3Dcode& >>>>>> client_id=3D123& >>>>>> state=3D456& >>>>>> scope=3Dread-all& >>>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>>=20 >>>>>> (And if the authorization server saw a value it didn't like in = the final parameter, it would reject the request.) >>>>>>=20 >>>>>> This is obviously not appropriate in every authorization = scenario, but it is useful anytime there's a discovery process by which = apps learn about authorization servers from resource servers. Since it's = something of a common need, I wanted to see if there was any common = practice in how to name this parameter, or whether it's worth = registering a standard extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>>=20 >>>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Josh >>>>>>=20 >>>>>>=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 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_18E967A2-3846-4B1A-85E5-260255033BB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Or by OAuth 2 PoP.    


On Mar 17, 2015, at 6:00 PM, = Bill Mills <wmills_92105@yahoo.com> wrote:

"Yes but it is custom.  People are inventing structured = scopes like "aud:https://foo.com", = and that potentially doesn't solve the security issue if a client just = passes on the scopes it receives in the error response, the bad RS just = adds a scope for the good RS."

This isn't solved by "aud", it is solved by OAuth 1.0a = though....
 



On Tuesday, = March 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


=
Yes but it is custom.  People are inventing structured = scopes like "aud:https://foo.com", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS.

The client = then potentially needs to understand the custom structures scopes of = every AS it might deal with.

I think that would lead to lots of problems = trying to make that a pattern long term.   At teh moment yes you = can do it with a scope as long as the client and AS both understand what = is going on.


We added "aud" as a separate parameter for PoP = as the token format for different RS might be different as well as the = symmetric  pop keys needing to be encrypted with different = keys.
Yes we could have invented a = special scope to carry the audience but a separate parameter was much = cleaner.

I know some = people have started using "aud" as a way to communicate the resource = when a scope applies to multiple RS but they may take different token = formats JWT vs opaque etc.

Brian commented that the "aud" parameter may be = useful beyond PoP so we might want to think about documenting it in it's = own mini spec, if I understood him correctly.

I think that = may not be a bad idea as we are also planning on using it in = NAPPS.

John = B.

On Mar 17, 2015, at 5:39 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

I don't think it's = "overloading scope names" to use them that way.  The aud value(s) = could as easily be carried in scope as anywhere.  Nothing says a = scope can't be "https://foo.com", and = that Foo.com requires that = scope to be present for a token to be accepted.  I would not make = it foo.com-read-mail for = example.

If it's more = convenient to put it in aud I can accept that, but it's the same = functionality and can be implemented in scopes now.



On = Tuesday, March 17, 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
People have been = overloading scope names to create implicit audience.   

The problem = is that clients need to know via some magic method that you need to ask = for scope "purple" to get write access to RS 2.

Having an = explicit "aud" parameter gives clients a way to communicate to the AS = what RS they are asking for a token for. 

the security = issue is that if a client discovers a API out via some out of band = mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y.  

Unfortunately = without POP tokens or at-least passing the URI of the RS to the AS via = "aud", a bad RS could get a legitimate client to give it a token that = can be replayed at a legitimate RS.

This was one of the issues that Eran = Hammer-Lahav was particularly concerned about.  

I think I = proposed a "aud" parameter to the token endpoint back then as a = alternative to requiring HMAC tokens, but that got lost in the confusion = at the time.

At that time = though people were not yet thinking about interoperable OAuth API, =  only relatively tightly bound clients that were preconfigured for = the API endpoints they were using.

In Health and other places we are starting to = see standard clients that discover API endpoints and configure = themselves based on a users Identity to use a arbitrary OAuth AS, moving = into federation of AT.

That is one of the reasons POP will be = important, as it prevents RS from misusing federated tokens by = presenting them at other RS.

The simplest thing to do is have the client say = what RS it is trying to access explicitly (The "aud" parameter), and = including an audience in the AT.  to protect against malicious = RS.

PoP is the = step up that also protects against tokens being intercepted and replayed = by another client.

John = B.

On Mar 17, 2015, at 4:10 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

This may have been hashed out already and I = missed it, but "aud" just becomes another kind of scope, = correct?




On = Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
You could do that, but it is probably safer for = the AS to know what RS it can issue tokens for and refuse to issue a = token for RS A to a client asking for a token with RS X as the = aud.

John B.
On Mar 16, 2015, at 8:27 PM, = Dixie Baker <Dixie.Baker@martin-blanck.co= m> wrote:

The threat that RFC6819 4.6.4 describes = is when a client obtains an AT and then sends it to a counterfeit RS, = which then uses the AT to access resources from a legitimate RS, on the = end-user's behalf.  

The suggested = countermeasure is a bit difficult to interpret:  "Associate the = endpoint URL of the resource server the client talked to with the access = token (e.g., in an audience field) and validate the association at a = legitimate resource server.  The endpoint URL validation policy may = be strict (exact match) or more relaxed (e.g., same host).  This = would require telling the authorization server about the resource server = endpoint URL in the authorization process."  

As I read = this, the suggestion is to have the client pass the URL of the bad RS in = the request to the AS (using the audience field).  The AS then = would include that RS URL in the AT.  Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request.  

-Dixie



Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 11:39 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Brian and I were talking about "aud" = used as a parameter to the token endpoint when using a code or refresh = token to indicate what RS the resulting AT will be used at.

Sending a = audience in the AT wouldn't help prevent the attack being discussed, =  though it may stop other sorts of attacks if the RS can tell if a = AT was issued for it or another RS.

In PoP having the AS check that you are sending = the AT to the correct RS is less important as the AT if stolen can't be = used to replay against the real AS.

Though depending on the app the bogus RS feeding = the app the wrong info may well be a problem as well.

John = B.

On = Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

I don't think putting an aud into an AT will = help to prevent counterfeit RSs (as long as the aud is nit directly = derived from the original URL used by the client to invoke the = counterfeit RS. as long as the aud is a symbolic name of any kind, the = counterfeit RS will accept ATs for the legitimate RS and just (ab)use = it.

POP on the = contrary helps since the counterfeit RS, in order to send a message to = the legitimate RS, needs to produce a new digitally signed message using = the correct secret, which it doesn't know.

kind = regards,
Torsten.



Am = 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.co= m>:

Using the "aud" parameter makes sense to me. =  Good suggestion.

Authenticating = the client to the RS would not address the counterfeit RS = threat. 

-Dixie

 
Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 6:43 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

We've used "aud" (optionally) = with OAuth 2 and bearer tokens to help identify the RS to whom the AT = should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I= do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:
In POP key = distribution we do introduce a "audiance" parameter to the = token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distr= ibution-01#section-3.1

It would be = possible to have a small spec to define using "aud" with bearer tokens, = however that would be undefined behaviour at this point.

I don't know = of any clients that would try to access a RS server and then besed on = the error response try and get a access token from the AS specified in = the error.

In POP we are = trying to both protect agains that attack and more common ones like = doing a MiM to intercept the AT or the RS being hacked and leaking the = token.

Using "aud" = with bearer tokens would be useful, but probably won't stop the majority = of possible AT leaks.

John = B.


On Mar 15, 2015, at 2:18 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.i= etf.org/html/rfc6819#section-5.4.2).

Please take a look onto http= ://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access = Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation = would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?<= /div>
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&= amp;
resource_server_that_told_me_to_authorize_here=3D<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv2022977117" = target=3D"_blank" = href=3D"https://attacker.com/">https://attacker.com

(And if the authorization server = saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate = in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.x= html . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? = The name I used in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


=



=



=

= --Apple-Mail=_18E967A2-3846-4B1A-85E5-260255033BB1-- --Apple-Mail=_A6E654A3-8441-4596-B4D8-D7F68D0B3F50 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTcyMTExNTZaMCMGCSqGSIb3DQEJBDEWBBQE2kFGmRZeuQmZvipTOskN 4vQ/zDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAXqv1+lEJrtZCqE5gkcBRjAhHoE9UmTXoztqjhYTULVe8x+jDv0/OU c47qzQ4PVeYBlwQdGnxcNfJY80m3cpMWrsgZk/L4iTOztUVpxe0sThCdKLskROhwHgttKURF+RUr d2Um2pFDWFjJ/STPbd5/IvRe4NhGUNr3Qh/R/mplNmbcw0xkCVs637BdHP7EwhvByduSaZtOxCRY +GvpVTIQcIVcJ6u5tQLEIXviNsEHe2pmmbFMwKoZtZQKxun7Jo426UvVRyQaff9CVXJ/DPa34G9f 5ORMc+GRZpkW0x0EtKXrLB5cy5avHVq0jX/H9OZ0Pb912xxCkCL93qdmY3+dAAAAAAAA --Apple-Mail=_A6E654A3-8441-4596-B4D8-D7F68D0B3F50-- From nobody Tue Mar 17 14:15:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444CD1A88F8 for ; Tue, 17 Mar 2015 14:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 qFh-Bx7uvMtx for ; Tue, 17 Mar 2015 14:15:02 -0700 (PDT) Received: from nm50-vm2.bullet.mail.bf1.yahoo.com (nm50-vm2.bullet.mail.bf1.yahoo.com [216.109.115.221]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5901A88F3 for ; Tue, 17 Mar 2015 14:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426626901; bh=UaBDitpk21Z1iC/pHHLRc0pn5e9dq7RUGTHDq2ZPxjU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=mhBZA/r6odLDQwAvlV0ZLxORnI0/2VxL5pkcHfUxp02mU8swzTXKPFt0jHxu2rxUvytdkUwttGpvS2KOylaEvf0hoTdAwmtWsQz/GLFnNubNLwdzmZboyVChB+FLW0qNRFUhC35QD9i3zTMw5Ty9OmSLR83tuzkuk9Ppr/qg5UdssQrPd6iqkuHo4DnWlH6A39ozMBv4eSJegF5uiSCz1MQamC7Wm079F1a3tNSbbVpD+rBEJwiAEjw9e11UVDv8WSDfqmhl7OVYZfs5yPXlTBl+qZu6u/k21wP1G7c1W2HE3FdTxKY3v049EHUCxcmreIiXf18jeKmKFmIe/Bs2SA== Received: from [98.139.215.143] by nm50.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:15:01 -0000 Received: from [98.139.212.216] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:15:00 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:15:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 942077.87097.bm@omp1025.mail.bf1.yahoo.com X-YMail-OSG: B_oXH_IVM1klngB2KbZE1yub_fQegnq.wyD1ejSqIxwtNXhly9cn7GCWOeXWPy4 hOgvlxnfM50O_tvBpvR7kM7QWkdZn.kDJQwVjQabwLIuzjWnUwiMFd5FRTH_5PwF_MHLPXs7Ch1M EIIc34rsWXGVejOV9KLH91F7tffDn7eHR1BFBeXSffBoYAmficEgIwDF5yC8vsrCwU3aptZjD_up s_ZO3BRfMmcOsg1Tsf9.PK.ZsY94J4ACEas09iIAUtud9mSnBChsObPtBWtKZhfr88sfd5ZSAtWi hpz58EstZ6_W0JD.TrbzZ9QIQA2equJRm7HyRBNH5_Ed.9jpbyZW1XvKfearC.XNFqN8DtCPJZQ8 CZkpJ9B4wcSEODQ3aBtVVdmfMCHdDIr3TePguuJlOXzOvWWq96.nbh6TgFAC2V._0uQWgZAIKrtF xaK8SbYn2XnqNMo5_JH4uYacE7jmW0xbaMruAQ8.5m8q8GWHq4D00ksx5suN0p5869zRqBB_2yvn BAdZh4ijfKBWV_V0KtLht0rZfsUo3NUyXnnL2sPk8mU8j7EN99hwRGcm38IKztpgfSLxDF0q00th t4S1nyvRq Received: by 66.196.81.108; Tue, 17 Mar 2015 21:15:00 +0000 Date: Tue, 17 Mar 2015 21:14:59 +0000 (UTC) From: Bill Mills To: John Bradley Message-ID: <237921450.154161.1426626899995.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_154160_1769201819.1426626899970" Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:15:06 -0000 ------=_Part_154160_1769201819.1426626899970 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes. =C2=A0There's still the open question of whether/how PoP tokens can be= proxied internally within a site though. =C2=A0If they can be proxied then= it goes back to unsolved.=20 On Tuesday, March 17, 2015 2:12 PM, John Bradley w= rote: =20 Or by OAuth 2 PoP. =C2=A0 =C2=A0 On Mar 17, 2015, at 6:00 PM, Bill Mills wrote: "Yes but it is custom. =C2=A0People are inventing structured scopes like "a= ud:https://foo.com", and that potentially doesn't solve the security issue = if a client just passes on the scopes it receives in the error response, th= e bad RS just adds a scope for the good RS." This isn't solved by "aud", it is solved by OAuth 1.0a though.... =C2=A0 On Tuesday, March 17, 2015 1:54 PM, John Bradley w= rote: =20 Yes but it is custom. =C2=A0People are inventing structured scopes like "a= ud:https://foo.com", and that potentially doesn't solve the security issue = if a client just passes on the scopes it receives in the error response, th= e bad RS just adds a scope for the good RS. The client then potentially needs to understand the custom structures scope= s of every AS it might deal with. I think that would lead to lots of problems trying to make that a pattern l= ong term. =C2=A0 At teh moment yes you can do it with a scope as long as th= e client and AS both understand what is going on. We added "aud" as a separate parameter for PoP as the token format for diff= erent RS might be different as well as the symmetric =C2=A0pop keys needing= to be encrypted with different keys.Yes we could have invented a special s= cope to carry the audience but a separate parameter was much cleaner. I know some people have started using "aud" as a way to communicate the res= ource when a scope applies to multiple RS but they may take different token= formats JWT vs opaque etc. Brian commented that the "aud" parameter may be useful beyond PoP so we mig= ht want to think about documenting it in it's own mini spec, if I understoo= d him correctly. I think that may not be a bad idea as we are also planning on using it in N= APPS. John B. On Mar 17, 2015, at 5:39 PM, Bill Mills wrote: I don't think it's "overloading scope names" to use them that way. =C2=A0Th= e aud value(s) could as easily be carried in scope as anywhere. =C2=A0Nothi= ng says a scope can't be "https://foo.com", and that Foo.com requires that = scope to be present for a token to be accepted. =C2=A0I would not make it f= oo.com-read-mail for example. If it's more convenient to put it in aud I can accept that, but it's the sa= me functionality and can be implemented in scopes now.=20 On Tuesday, March 17, 2015 12:41 PM, John Bradley = wrote: =20 People have been overloading scope names to create implicit audience. =C2= =A0=C2=A0 The problem is that clients need to know via some magic method that you nee= d to ask for scope "purple" to get write access to RS 2. Having an explicit "aud" parameter gives clients a way to communicate to th= e AS what RS they are asking for a token for.=C2=A0 the security issue is that if a client discovers a API out via some out of = band mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y. =C2=A0 Unfortunately without POP tokens or at-least passing the URI of the RS to t= he AS via "aud", a bad RS could get a legitimate client to give it a token = that can be replayed at a legitimate RS. This was one of the issues that Eran Hammer-Lahav was particularly concerne= d about. =C2=A0 I think I proposed a "aud" parameter to the token endpoint back then as a a= lternative to requiring HMAC tokens, but that got lost in the confusion at = the time. At that time though people were not yet thinking about interoperable OAuth = API, =C2=A0only relatively tightly bound clients that were preconfigured fo= r the API endpoints they were using. In Health and other places we are starting to see standard clients that dis= cover API endpoints and configure themselves based on a users Identity to u= se a arbitrary OAuth AS, moving into federation of AT. That is one of the reasons POP will be important, as it prevents RS from mi= susing federated tokens by presenting them at other RS. The simplest thing to do is have the client say what RS it is trying to acc= ess explicitly (The "aud" parameter), and including an audience in the AT. = =C2=A0to protect against malicious RS. PoP is the step up that also protects against tokens being intercepted and = replayed by another client. John B. On Mar 17, 2015, at 4:10 PM, Bill Mills wrote: This may have been hashed out already and I missed it, but "aud" just becom= es another kind of scope, correct? =20 On Tuesday, March 17, 2015 8:50 AM, John Bradley w= rote: =20 You could do that, but it is probably safer for the AS to know what RS it = can issue tokens for and refuse to issue a token for RS A to a client askin= g for a token with RS X as the aud. John B. On Mar 16, 2015, at 8:27 PM, Dixie Baker wr= ote: The threat that RFC6819 4.6.4 describes is when a client obtains an AT and = then sends it to a counterfeit RS, which then uses the AT to access resourc= es from a legitimate RS, on the end-user's behalf. =C2=A0 The suggested countermeasure is a bit difficult to interpret: =C2=A0"Associ= ate the endpoint URL of the resource server the client talked to with the a= ccess token (e.g., in an audience field) and validate the association at a = legitimate resource server. =C2=A0The endpoint URL validation policy may be= strict (exact match) or more relaxed (e.g., same host). =C2=A0This would r= equire telling the authorization server about the resource server endpoint = URL in the authorization process." =C2=A0 As I read this, the suggestion is to have the client pass the URL of the ba= d RS in the request to the AS (using the audience field). =C2=A0The AS then= would include that RS URL in the AT. =C2=A0Then, when the client passes th= e AT to the bad RS, and it passes it on to the good RS, the good RS will ch= eck the audience field, compare that URL with its own, and refuse the reque= st. =C2=A0 -Dixie Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 11:39 AM, John Bradley wrote: Brian and I were talking about "aud" used as a parameter to the token endpo= int when using a code or refresh token to indicate what RS the resulting AT= will be used at. Sending a audience in the AT wouldn't help prevent the attack being discuss= ed, =C2=A0though it may stop other sorts of attacks if the RS can tell if a= AT was issued for it or another RS. In PoP having the AS check that you are sending the AT to the correct RS is= less important as the AT if stolen can't be used to replay against the rea= l AS. Though depending on the app the bogus RS feeding the app the wrong info may= well be a problem as well. John B. On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = wrote: I don't think putting an aud into an AT will help to prevent counterfeit RS= s (as long as the aud is nit directly derived from the original URL used by= the client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate RS = and just (ab)use it. POP on the contrary helps since the counterfeit RS, in order to send a mess= age to the legitimate RS, needs to produce a new digitally signed message u= sing the correct secret, which it doesn't know. kind regards,Torsten. Am 16.03.2015 um 17:40 schrieb Dixie Baker : Using the "aud" parameter makes sense to me. =C2=A0Good suggestion. Authenticating the client to the RS would not address the counterfeit RS th= reat.=C2=A0 -Dixie =C2=A0 Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 6:43 AM, Brian Campbell wr= ote: We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identi= fy the RS to whom the AT should be issued. It is useful but it's mostly abo= ut getting format/content/etc of the AT correct for the RS rather than it i= s about preventing possible AT leaks. I do think an "aud(iance)" parameter at both token and authorization endpoi= nts would have utility beyond the POP work. So defining it independently mi= ght make sense.=20 On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: In POP key distribution we do introduce a "audiance" parameter to the token= _endpoint.=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distri= bution-01#section-3.1 It would be possible to have a small spec to define using "aud" with bearer= tokens, however that would be undefined behaviour at this point. I don't know of any clients that would try to access a RS server and then b= esed on the error response try and get a access token from the AS specified= in the error. In POP we are trying to both protect agains that attack and more common one= s like doing a MiM to intercept the AT or the RS being hacked and leaking t= he token. Using "aud" with bearer tokens would be useful, but probably won't stop the= majority of possible AT leaks. John B. On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = wrote: Hi Josh, =20 I'm not aware of a common practice to use such a parameter. The WG is inst= ead heading towards authenticated requests to the resource server (see http= s://tools.ietf.org/html/rfc6819#section-5.4.2).=20 =20 Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-ar= chitecture and further drafts on this topic. =20 kind regards, Torsten. =20 Am 03.03.2015 um 18:27 schrieb Josh Mandel: =20 Hi All,=20 In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource = Server"), RFC6819 describes a threat where a counterfeit resource server tr= icks a client into obtaining and sharing an access token from a legitimate = authorization server. One of the proposed mitigations involves: "telling th= e authorization server about the resource server endpoint URL in the author= ization process."=20 In other words, this mitigation would ask the client to pass an additiona= l parameter when redirecting to the Authorization server's "authorize" URL,= effectively something like:=20 https://auth-server/authorize? response_type=3Dcode& client_id=3D123& st= ate=3D456& scope=3Dread-all& redirect_uri=3Dhttps://app-server/after-auth& resourc= e_server_that_told_me_to_authorize_here=3Dhttps://attacker.com =20 (And if the authorization server saw a value it didn't like in the final = parameter, it would reject the request.)=20 This is obviously not appropriate in every authorization scenario, but it= is useful anytime there's a discovery process by which apps learn about au= thorization servers from resource servers. Since it's something of a common= need, I wanted to see if there was any common practice in how to name this= parameter, or whether it's worth registering a standard extension at=C2=A0= http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (= I don't see one there now -- possibly I'm just missing it.)=20 If so, what should it be called? The name I used in the example above is = a bit verbose :-)=20 Best,=20 =C2=A0 Josh =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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 ------=_Part_154160_1769201819.1426626899970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes.  There's still the open= question of whether/how PoP tokens can be proxied internally within a site= though.  If they can be proxied then it goes back to unsolved.=



On Tuesday, March 17, 2015 2:12 PM, John Brad= ley <ve7jtb@ve7jtb.com> wrote:


Or by OAuth 2 PoP. &nb= sp;  


On Mar 17, 2015, at 6:00 PM, Bill Mills <wmills_9= 2105@yahoo.com> wrote:

"Yes but it is custom.  People are inventing structured scopes = like "aud:https://foo.com", and that pote= ntially doesn't solve the security issue if a client just passes on the sco= pes it receives in the error response, the bad RS just adds a scope for the= good RS."

<= /div>
This = isn't solved by "aud", it is solved by OAuth 1.0a though....<= /div>
 

=


On Tuesday, M= arch 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


Yes but it is custom.  People = are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't solve the security issue if a = client just passes on the scopes it receives in the error response, the bad= RS just adds a scope for the good RS.

The c= lient then potentially needs to understand the custom structures scopes of = every AS it might deal with.

I think t= hat would lead to lots of problems trying to make that a pattern long term.=   At teh moment yes you can do it with a scope as long as the client = and AS both understand what is going on.
=

We added "aud" as a separate parameter for PoP as the token format fo= r different RS might be different as well as the symmetric  pop keys n= eeding to be encrypted with different keys.
Yes we could have invented a special scope to carry the audience but a s= eparate parameter was much cleaner.

I = know some people have started using "aud" as a way to communicate the resou= rce when a scope applies to multiple RS but they may take different token f= ormats JWT vs opaque etc.

Brian commen= ted that the "aud" parameter may be useful beyond PoP so we might want to t= hink about documenting it in it's own mini spec, if I understood him correc= tly.

I think that may not be a bad ide= a as we are also planning on using it in NAPPS.

John B.

<= blockquote class=3D"yiv0739021482" type=3D"cite">
On Mar 17, 2015, at 5:39 PM, Bill Mills <wmills_92105@yahoo.c= om> wrote:

<= div class=3D"yiv0739021482" style=3D"background-color:rgb(255, 255, 255);fo= nt-family:HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande= ', sans-serif;font-size:12px;">
I don't think it's "overloading scope names" to = use them that way.  The aud value(s) could as easily be carried in sco= pe as anywhere.  Nothing says a scope can't be "https://foo.com", and that Foo.com= requires that scope to be present for a token to be accepted.  I woul= d not make it foo.com-read-mail for example.=

If = it's more convenient to put it in aud I can accept that, but it's the same = functionality and can be implemented in scopes now.



On Tuesday, March 17, 2015 12:41 PM, John Bradley <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv0739021482" ymailto=3D"mailto= :ve7jtb@ve7jtb.com" target=3D"_blank" href=3D"mailto:ve7jtb@ve7jtb.com">ve7= jtb@ve7jtb.com> wrote:


P= eople have been overloading scope names to create implicit audience.  =  

The problem is that clients need to k= now via some magic method that you need to ask for scope "purple" to get wr= ite access to RS 2.

Having an explicit "aud"= parameter gives clients a way to communicate to the AS what RS they are as= king for a token for. 

the security issue is that if a client discovers= a API out via some out of band mechanism the OAuth error code can tell the= client go to AS X and ask for Scope Y.  

Unfortunately without POP tokens or at-least passing the URI of th= e RS to the AS via "aud", a bad RS could get a legitimate client to give it= a token that can be replayed at a legitimate RS.

This was one of the issues that Eran Hammer-Lahav was particula= rly concerned about.  

I think I = proposed a "aud" parameter to the token endpoint back then as a alternative= to requiring HMAC tokens, but that got lost in the confusion at the time.<= /div>

At that time though people were not ye= t thinking about interoperable OAuth API,  only relatively tightly bou= nd clients that were preconfigured for the API endpoints they were using.

In Health and other places we are start= ing to see standard clients that discover API endpoints and configure thems= elves based on a users Identity to use a arbitrary OAuth AS, moving into fe= deration of AT.

That is one of the re= asons POP will be important, as it prevents RS from misusing federated toke= ns by presenting them at other RS.

The= simplest thing to do is have the client say what RS it is trying to access= explicitly (The "aud" parameter), and including an audience in the AT. &nb= sp;to protect against malicious RS.

Po= P is the step up that also protects against tokens being intercepted and re= played by another client.

John B.

=
On Mar 17, 20= 15, at 4:10 PM, Bill Mills <wmills_92105@yahoo.com> wrote= :

=
This may hav= e been hashed out already and I missed it, but "aud" just becomes another k= ind of scope, correct?




On Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:


You could do that, but it is probably safer for = the AS to know what RS it can issue tokens for and refuse to issue a token = for RS A to a client asking for a token with RS X as the aud.

John B.
<= div class=3D"yiv0739021482yqt4013611375" id=3D"yiv0739021482yqt73071">
<= div class=3D"yiv0739021482">On Mar 16, 2015, at 8:27 PM, Dixie Baker <Dixie.Baker@martin-blanck.com> wrote:

Th= e threat that RFC6819 4.6.4 describes is when a client obtains an AT and th= en sends it to a counterfeit RS, which then uses the AT to access resources= from a legitimate RS, on the end-user's behalf.  

The suggested countermeasure is a bit difficult to interpret: &= nbsp;"Associate the endpoint URL of the resource server the client talked t= o with the access token (e.g., in an audience field) and validate the assoc= iation at a legitimate resource server.  The endpoint URL validation p= olicy may be strict (exact match) or more relaxed (e.g., same host).  = This would require telling the authorization server about the resource serv= er endpoint URL in the authorization process."  

As I read this, the suggestion is to have the client pass t= he URL of the bad RS in the request to the AS (using the audience field). &= nbsp;The AS then would include that RS URL in the AT.  Then, when the = client passes the AT to the bad RS, and it passes it on to the good RS, the= good RS will check the audience field, compare that URL with its own, and = refuse the request.  

-Dixie



Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 11:39 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:

<= div class=3D"yiv0739021482" style=3D"word-wrap:break-word;">Brian and I wer= e talking about "aud" used as a parameter to the token endpoint when using = a code or refresh token to indicate what RS the resulting AT will be used a= t.

<= /div>
Sending a audience in the AT wouldn't hel= p prevent the attack being discussed,  though it may stop other sorts = of attacks if the RS can tell if a AT was issued for it or another RS.

In PoP having the AS check that you are se= nding the AT to the correct RS is less important as the AT if stolen can't = be used to replay against the real AS.
Though depending on the app the bogus RS feeding the app the wrong info ma= y well be a problem as well.

John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodd= erstedt <torsten@lodderstedt.net> wrote:

I don't= think putting an aud into an AT will help to prevent counterfeit RSs (as l= ong as the aud is nit directly derived from the original URL used by the cl= ient to invoke the counterfeit RS. as long as the aud is a symbolic name of= any kind, the counterfeit RS will accept ATs for the legitimate RS and jus= t (ab)use it.

POP on the contrary help= s since the counterfeit RS, in order to send a message to the legitimate RS= , needs to produce a new digitally signed message using the correct secret,= which it doesn't know.

kind regards,<= /div>
Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "au= d" parameter makes sense to me.  Good suggestion.

Authenticating the client to the RS would not address the counte= rfeit RS threat. 

-Dixie

=
 
Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv0739021482" ymailto=3D"mailto= :bcampbell@pingidentity.com" target=3D"_blank" href=3D"mailto:bcampbell@pin= gidentity.com">bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 and bea= rer tokens to help identify the RS to whom the AT should be issued. It is u= seful but it's mostly about getting format/content/etc of the AT correct fo= r the RS rather than it is about preventing possible AT leaks.

I do think an "aud(iance)" parameter at both token and authorization en= dpoints would have utility beyond the POP work. So defining it independentl= y might make sense.

On Sun, Mar 15, 2015 at 11:34 AM,= John Bradley <ve7jtb@ve7jtb.com= > wrote:
In POP key distribution we do introduce a "audiance" p= arameter to the token_endpoint. https://tools.ietf.or= g/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1

It would be possible to have a small spec to define u= sing "aud" with bearer tokens, however that would be undefined behaviour at= this point.

I don't know of any clien= ts that would try to access a RS server and then besed on the error respons= e try and get a access token from the AS specified in the error.

In POP we are trying to both protect agains that= attack and more common ones like doing a MiM to intercept the AT or the RS= being hacked and leaking the token.

U= sing "aud" with bearer tokens would be useful, but probably won't stop the = majority of possible AT leaks.

John B= .


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt &= lt;torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Toke= n Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would = ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_= server_that_told_me_to_authorize_here=3Dht= tps://attacker.com

(And if the authorization server saw a= value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in e= very authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-p= arameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The n= ame I used in the example above is a bit verbose :-)

Best,

  Josh


________________________________________=
_______
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org=
/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oau= th
<= br clear=3D"none" class=3D"yiv0739021482">

_________________________________________= ______
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth



<= /div>

=
<= /div>

=
<= /div>

------=_Part_154160_1769201819.1426626899970-- From nobody Tue Mar 17 14:26:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBD61A88F8 for ; Tue, 17 Mar 2015 14:26:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 sKaojDPwV3uz for ; Tue, 17 Mar 2015 14:26:42 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (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 045061A88F7 for ; Tue, 17 Mar 2015 14:26:41 -0700 (PDT) Received: by qcyi15 with SMTP id i15so22032406qcy.0 for ; Tue, 17 Mar 2015 14:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vkg4M9ROFqM3+cAlEo6IG6KAsh0MnX0QJkdHCE9bHL8=; b=Q7YxtqWFou+kOyPwO7JS4m2ptnJEF208qK8gcW4lUYZXA/H7MHh5T8TB3aaawbEXyD 9RPku193mFjcY894OruRoRhjgYiiOf6AUPhs2iPeB3SWrNlJ3PxHsiS1Zos45apVeMVz 48f2fmuRWOoz/msI40tr2kzVdYGaBGffqLgfPNu/eexvoggFy2aFbuDAB5DW5NK8y8/u mxLgT9X0JWHxtmLhWtWj314go7ChaAtuzDTLvLDwqObs4WkWExz1+RJOuWys61MAXgKP TtygpSmNeLH7kAXqBCnI1KitHl2dBcRmdj18n8qevu2NEFL0byGs7FMQlby7nBuIyoss JQNw== X-Gm-Message-State: ALoCoQnMFjMojJl5l5KLoGcgOQ71iKFwnkvagvr8C91myJWiLsMf8fJyL2Xi3QTuI4dAM3I9Omt4 X-Received: by 10.55.54.71 with SMTP id d68mr136306219qka.42.1426627601125; Tue, 17 Mar 2015 14:26:41 -0700 (PDT) Received: from [192.168.8.100] ([181.202.4.92]) by mx.google.com with ESMTPSA id 142sm10447058qhg.16.2015.03.17.14.26.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 14:26:40 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BE593293-6221-4BA2-9CF3-F134AF1B930C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <237921450.154161.1426626899995.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Mar 2015 18:26:36 -0300 Message-Id: References: <237921450.154161.1426626899995.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:26:48 -0000 --Apple-Mail=_BE593293-6221-4BA2-9CF3-F134AF1B930C Content-Type: multipart/alternative; boundary="Apple-Mail=_849D3990-0021-42BB-A753-4032A60F9101" --Apple-Mail=_849D3990-0021-42BB-A753-4032A60F9101 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii PoP tokens need to be presented with a proof the presenter knows the = secret. That is the same principal as in OAuth 1.0a with needing to = show knowledge of the "token secret". I don't know what you mean by proxies internally. If the RS needs = another token to access a resource it should use the assertion flow and = authenticate itself to get another token based on the access token. Passing around a PoP token as a bearer token is insecure/bad. In OAuth 1.0a because of the tight relationship between the "Service = Provider" and the "Protected Resource" people would be less likely to = try it but because the protected resource knows the "token secret" it = could still do lots of unexpected bad things. Proxying access tokens is not something RS should do, they need to be = exchanged at a AS for a new AT with the correct rights and optionally = binding it to a new PoP key. John B. On Mar 17, 2015, at 6:14 PM, Bill Mills wrote: >=20 > Yes. There's still the open question of whether/how PoP tokens can be = proxied internally within a site though. If they can be proxied then it = goes back to unsolved. >=20 >=20 >=20 > On Tuesday, March 17, 2015 2:12 PM, John Bradley = wrote: >=20 >=20 > Or by OAuth 2 PoP. =20 >=20 >=20 >> On Mar 17, 2015, at 6:00 PM, Bill Mills > wrote: >>=20 >> "Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS." >>=20 >> This isn't solved by "aud", it is solved by OAuth 1.0a though.... >> =20 >>=20 >>=20 >>=20 >> On Tuesday, March 17, 2015 1:54 PM, John Bradley > wrote: >>=20 >>=20 >> Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS. >>=20 >> The client then potentially needs to understand the custom structures = scopes of every AS it might deal with. >>=20 >> I think that would lead to lots of problems trying to make that a = pattern long term. At teh moment yes you can do it with a scope as = long as the client and AS both understand what is going on. >>=20 >>=20 >> We added "aud" as a separate parameter for PoP as the token format = for different RS might be different as well as the symmetric pop keys = needing to be encrypted with different keys. >> Yes we could have invented a special scope to carry the audience but = a separate parameter was much cleaner. >>=20 >> I know some people have started using "aud" as a way to communicate = the resource when a scope applies to multiple RS but they may take = different token formats JWT vs opaque etc. >>=20 >> Brian commented that the "aud" parameter may be useful beyond PoP so = we might want to think about documenting it in it's own mini spec, if I = understood him correctly. >>=20 >> I think that may not be a bad idea as we are also planning on using = it in NAPPS. >>=20 >> John B. >>=20 >>> On Mar 17, 2015, at 5:39 PM, Bill Mills > wrote: >>>=20 >>> I don't think it's "overloading scope names" to use them that way. = The aud value(s) could as easily be carried in scope as anywhere. = Nothing says a scope can't be "https://foo.com ", and = that Foo.com requires that scope to be present for a = token to be accepted. I would not make it foo.com = -read-mail for example. >>>=20 >>> If it's more convenient to put it in aud I can accept that, but it's = the same functionality and can be implemented in scopes now. >>>=20 >>>=20 >>>=20 >>> On Tuesday, March 17, 2015 12:41 PM, John Bradley > wrote: >>>=20 >>>=20 >>> People have been overloading scope names to create implicit = audience. =20 >>>=20 >>> The problem is that clients need to know via some magic method that = you need to ask for scope "purple" to get write access to RS 2. >>>=20 >>> Having an explicit "aud" parameter gives clients a way to = communicate to the AS what RS they are asking for a token for.=20 >>>=20 >>> the security issue is that if a client discovers a API out via some = out of band mechanism the OAuth error code can tell the client go to AS = X and ask for Scope Y. =20 >>>=20 >>> Unfortunately without POP tokens or at-least passing the URI of the = RS to the AS via "aud", a bad RS could get a legitimate client to give = it a token that can be replayed at a legitimate RS. >>>=20 >>> This was one of the issues that Eran Hammer-Lahav was particularly = concerned about. =20 >>>=20 >>> I think I proposed a "aud" parameter to the token endpoint back then = as a alternative to requiring HMAC tokens, but that got lost in the = confusion at the time. >>>=20 >>> At that time though people were not yet thinking about interoperable = OAuth API, only relatively tightly bound clients that were = preconfigured for the API endpoints they were using. >>>=20 >>> In Health and other places we are starting to see standard clients = that discover API endpoints and configure themselves based on a users = Identity to use a arbitrary OAuth AS, moving into federation of AT. >>>=20 >>> That is one of the reasons POP will be important, as it prevents RS = from misusing federated tokens by presenting them at other RS. >>>=20 >>> The simplest thing to do is have the client say what RS it is trying = to access explicitly (The "aud" parameter), and including an audience in = the AT. to protect against malicious RS. >>>=20 >>> PoP is the step up that also protects against tokens being = intercepted and replayed by another client. >>>=20 >>> John B. >>>=20 >>>> On Mar 17, 2015, at 4:10 PM, Bill Mills > wrote: >>>>=20 >>>> This may have been hashed out already and I missed it, but "aud" = just becomes another kind of scope, correct? >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Tuesday, March 17, 2015 8:50 AM, John Bradley > wrote: >>>>=20 >>>>=20 >>>> You could do that, but it is probably safer for the AS to know what = RS it can issue tokens for and refuse to issue a token for RS A to a = client asking for a token with RS X as the aud. >>>>=20 >>>> John B. >>>>> On Mar 16, 2015, at 8:27 PM, Dixie Baker = > = wrote: >>>>>=20 >>>>=20 >>>> The threat that RFC6819 4.6.4 describes is when a client obtains an = AT and then sends it to a counterfeit RS, which then uses the AT to = access resources from a legitimate RS, on the end-user's behalf. =20 >>>>=20 >>>> The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." =20 >>>>=20 >>>> As I read this, the suggestion is to have the client pass the URL = of the bad RS in the request to the AS (using the audience field). The = AS then would include that RS URL in the AT. Then, when the client = passes the AT to the bad RS, and it passes it on to the good RS, the = good RS will check the audience field, compare that URL with its own, = and refuse the request. =20 >>>>=20 >>>> -Dixie >>>>=20 >>>>=20 >>>>=20 >>>> Dixie B. Baker, Ph.D. >>>> Senior Partner >>>> Martin, Blanck and Associates >>>> Office (Redondo Beach, CA): 310-791-9671 >>>> Mobile: 310-279-2579 >>>>=20 >>>> On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >>>>=20 >>>>=20 >>>> Brian and I were talking about "aud" used as a parameter to the = token endpoint when using a code or refresh token to indicate what RS = the resulting AT will be used at. >>>>=20 >>>> Sending a audience in the AT wouldn't help prevent the attack being = discussed, though it may stop other sorts of attacks if the RS can tell = if a AT was issued for it or another RS. >>>>=20 >>>> In PoP having the AS check that you are sending the AT to the = correct RS is less important as the AT if stolen can't be used to replay = against the real AS. >>>>=20 >>>> Though depending on the app the bogus RS feeding the app the wrong = info may well be a problem as well. >>>>=20 >>>> John B. >>>>=20 >>>>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>>>>=20 >>>>=20 >>>> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>>>=20 >>>> POP on the contrary helps since the counterfeit RS, in order to = send a message to the legitimate RS, needs to produce a new digitally = signed message using the correct secret, which it doesn't know. >>>>=20 >>>> kind regards, >>>> Torsten. >>>>=20 >>>>=20 >>>>=20 >>>> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>>>=20 >>>>=20 >>>> Using the "aud" parameter makes sense to me. Good suggestion. >>>>=20 >>>> Authenticating the client to the RS would not address the = counterfeit RS threat.=20 >>>>=20 >>>> -Dixie >>>>=20 >>>> =20 >>>> Dixie B. Baker, Ph.D. >>>> Senior Partner >>>> Martin, Blanck and Associates >>>> Office (Redondo Beach, CA): 310-791-9671 >>>> Mobile: 310-279-2579 >>>>=20 >>>> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>>>=20 >>>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to = help identify the RS to whom the AT should be issued. It is useful but = it's mostly about getting format/content/etc of the AT correct for the = RS rather than it is about preventing possible AT leaks. >>>>>=20 >>>>> I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So = defining it independently might make sense.=20 >>>>>=20 >>>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>>>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>>>=20 >>>>> It would be possible to have a small spec to define using "aud" = with bearer tokens, however that would be undefined behaviour at this = point. >>>>>=20 >>>>> I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the = AS specified in the error. >>>>>=20 >>>>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>>>=20 >>>>> Using "aud" with bearer tokens would be useful, but probably won't = stop the majority of possible AT leaks. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>>>=20 >>>>>> Hi Josh, >>>>>>=20 >>>>>> I'm not aware of a common practice to use such a parameter. The = WG is instead heading towards authenticated requests to the resource = server (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>>>=20 >>>>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>>>=20 >>>>>> kind regards, >>>>>> Torsten. >>>>>>=20 >>>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>>> Hi All, >>>>>>>=20 >>>>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>>>=20 >>>>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>>>=20 >>>>>>> https://auth-server/authorize ? >>>>>>> response_type=3Dcode& >>>>>>> client_id=3D123& >>>>>>> state=3D456& >>>>>>> scope=3Dread-all& >>>>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>>>=20 >>>>>>> (And if the authorization server saw a value it didn't like in = the final parameter, it would reject the request.) >>>>>>>=20 >>>>>>> This is obviously not appropriate in every authorization = scenario, but it is useful anytime there's a discovery process by which = apps learn about authorization servers from resource servers. Since it's = something of a common need, I wanted to see if there was any common = practice in how to name this parameter, or whether it's worth = registering a standard extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>>>=20 >>>>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Josh >>>>>>>=20 >>>>>>>=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 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_849D3990-0021-42BB-A753-4032A60F9101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii PoP tokens need to be presented with a proof the presenter = knows the secret.  That is the same principal as in OAuth 1.0a with = needing to show knowledge of the "token secret".

I don't know what you mean by proxies = internally.   If the RS needs another token to access a resource it = should use the assertion flow and authenticate itself to get another = token based on the access token.
Passing around a = PoP token as a bearer token is insecure/bad.

In OAuth 1.0a because of the tight = relationship between the "Service Provider" and the "Protected Resource" = people would be less likely to try it but because the protected resource = knows the "token secret" it could still do lots of unexpected bad = things.

Proxying= access tokens is not something RS should do, they need to be exchanged = at a AS for a new AT with the correct rights and optionally binding it = to a new PoP key.

John B.



On Mar 17, 2015, at 6:14 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Yes.  There's = still the open question of whether/how PoP tokens can be proxied = internally within a site though.  If they can be proxied then it = goes back to unsolved.



On Tuesday, = March 17, 2015 2:12 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


=
Or by OAuth 2 PoP.    


On = Mar 17, 2015, at 6:00 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

"Yes but it is custom. =  People are inventing structured scopes like "aud:https://foo.com", and that potentially = doesn't solve the security issue if a client just passes on the scopes = it receives in the error response, the bad RS just adds a scope for the = good RS."

This isn't solved by "aud", it is solved by = OAuth 1.0a though....
 


On = Tuesday, March 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
Yes but it is custom. =  People are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS.

The client = then potentially needs to understand the custom structures scopes of = every AS it might deal with.

I think that would lead to lots of problems = trying to make that a pattern long term.   At teh moment yes you = can do it with a scope as long as the client and AS both understand what = is going on.


We added "aud" as a separate parameter for PoP = as the token format for different RS might be different as well as the = symmetric  pop keys needing to be encrypted with different = keys.
Yes we could have invented a = special scope to carry the audience but a separate parameter was much = cleaner.

I know some = people have started using "aud" as a way to communicate the resource = when a scope applies to multiple RS but they may take different token = formats JWT vs opaque etc.

Brian commented that the "aud" parameter may be = useful beyond PoP so we might want to think about documenting it in it's = own mini spec, if I understood him correctly.

I think that = may not be a bad idea as we are also planning on using it in = NAPPS.

John = B.

On Mar 17, 2015, at 5:39 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

I don't think it's = "overloading scope names" to use them that way.  The aud value(s) = could as easily be carried in scope as anywhere.  Nothing says a = scope can't be "https://foo.com", and = that Foo.com requires that = scope to be present for a token to be accepted.  I would not make = it foo.com-read-mail for = example.

If it's more = convenient to put it in aud I can accept that, but it's the same = functionality and can be implemented in scopes now.



On = Tuesday, March 17, 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
People have been = overloading scope names to create implicit audience.   

The problem = is that clients need to know via some magic method that you need to ask = for scope "purple" to get write access to RS 2.

Having an = explicit "aud" parameter gives clients a way to communicate to the AS = what RS they are asking for a token for. 

the security = issue is that if a client discovers a API out via some out of band = mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y.  

Unfortunately = without POP tokens or at-least passing the URI of the RS to the AS via = "aud", a bad RS could get a legitimate client to give it a token that = can be replayed at a legitimate RS.

This was one of the issues that Eran = Hammer-Lahav was particularly concerned about.  

I think I = proposed a "aud" parameter to the token endpoint back then as a = alternative to requiring HMAC tokens, but that got lost in the confusion = at the time.

At that time = though people were not yet thinking about interoperable OAuth API, =  only relatively tightly bound clients that were preconfigured for = the API endpoints they were using.

In Health and other places we are starting to = see standard clients that discover API endpoints and configure = themselves based on a users Identity to use a arbitrary OAuth AS, moving = into federation of AT.

That is one of the reasons POP will be = important, as it prevents RS from misusing federated tokens by = presenting them at other RS.

The simplest thing to do is have the client say = what RS it is trying to access explicitly (The "aud" parameter), and = including an audience in the AT.  to protect against malicious = RS.

PoP is the = step up that also protects against tokens being intercepted and replayed = by another client.

John = B.

On Mar 17, 2015, at 4:10 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

This may have been hashed out already and I = missed it, but "aud" just becomes another kind of scope, = correct?




On = Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
You could do that, but it is probably safer for = the AS to know what RS it can issue tokens for and refuse to issue a = token for RS A to a client asking for a token with RS X as the = aud.

John B.
On Mar 16, 2015, at 8:27 PM, = Dixie Baker <Dixie.Baker@martin-blanck.co= m> wrote:

The threat that RFC6819 4.6.4 describes = is when a client obtains an AT and then sends it to a counterfeit RS, = which then uses the AT to access resources from a legitimate RS, on the = end-user's behalf.  

The suggested = countermeasure is a bit difficult to interpret:  "Associate the = endpoint URL of the resource server the client talked to with the access = token (e.g., in an audience field) and validate the association at a = legitimate resource server.  The endpoint URL validation policy may = be strict (exact match) or more relaxed (e.g., same host).  This = would require telling the authorization server about the resource server = endpoint URL in the authorization process."  

As I read = this, the suggestion is to have the client pass the URL of the bad RS in = the request to the AS (using the audience field).  The AS then = would include that RS URL in the AT.  Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request.  

-Dixie



Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 11:39 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Brian and I were talking about "aud" = used as a parameter to the token endpoint when using a code or refresh = token to indicate what RS the resulting AT will be used at.

Sending a = audience in the AT wouldn't help prevent the attack being discussed, =  though it may stop other sorts of attacks if the RS can tell if a = AT was issued for it or another RS.

In PoP having the AS check that you are sending = the AT to the correct RS is less important as the AT if stolen can't be = used to replay against the real AS.

Though depending on the app the bogus RS feeding = the app the wrong info may well be a problem as well.

John = B.

On = Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

I don't think putting an aud into an AT will = help to prevent counterfeit RSs (as long as the aud is nit directly = derived from the original URL used by the client to invoke the = counterfeit RS. as long as the aud is a symbolic name of any kind, the = counterfeit RS will accept ATs for the legitimate RS and just (ab)use = it.

POP on the = contrary helps since the counterfeit RS, in order to send a message to = the legitimate RS, needs to produce a new digitally signed message using = the correct secret, which it doesn't know.

kind = regards,
Torsten.



Am = 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.co= m>:

Using the "aud" parameter makes sense to me. =  Good suggestion.

Authenticating = the client to the RS would not address the counterfeit RS = threat. 

-Dixie

 
Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 6:43 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

We've used "aud" (optionally) = with OAuth 2 and bearer tokens to help identify the RS to whom the AT = should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I= do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:
In POP key = distribution we do introduce a "audiance" parameter to the = token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distr= ibution-01#section-3.1

It would be = possible to have a small spec to define using "aud" with bearer tokens, = however that would be undefined behaviour at this point.

I don't know = of any clients that would try to access a RS server and then besed on = the error response try and get a access token from the AS specified in = the error.

In POP we are = trying to both protect agains that attack and more common ones like = doing a MiM to intercept the AT or the RS being hacked and leaking the = token.

Using "aud" = with bearer tokens would be useful, but probably won't stop the majority = of possible AT leaks.

John = B.


On Mar 15, 2015, at 2:18 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.i= etf.org/html/rfc6819#section-5.4.2).

Please take a look onto http= ://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access = Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation = would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?<= /div>
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&= amp;
resource_server_that_told_me_to_authorize_here=3D<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv0739021482" = target=3D"_blank" = href=3D"https://attacker.com/">https://attacker.com

(And if the authorization server = saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate = in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.x= html . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? = The name I used in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


=



=



=



=

= --Apple-Mail=_849D3990-0021-42BB-A753-4032A60F9101-- --Apple-Mail=_BE593293-6221-4BA2-9CF3-F134AF1B930C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTcyMTI2MzZaMCMGCSqGSIb3DQEJBDEWBBQ/HdI/5sTIkermMOFvidEd 564mTzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA76fGOhhAlIvAusXbC/RFjsUEDHzhg49O/j9uaarhUIVkI3ls8ZT8x r9WbwrEM5wBrtjJs8d1YXQ71zXJudpU3VZfKtY72C/RBygs/yzSBC0vkWvzOJQlUAwbKThfHMcMs AmP7V4lu7W3O+nT3p/PMwwCDZJ8ZGmQT3NOguupNqHZ1zhAi5/SrvxBMWU3CHXZLA8Nd6VyeapHI Zj26ddQ2tC9OLrGNIVfMZ8Rktb4ruKci8iDhAegDFHs9zjVQdvWl68MHkvAXSjebAhVzI0O2ldBW fMzrtqR2n4+sitWVfCW8YuTwNgjRehg6MwRcdfmxUUofu6GANrLnP6Dwc/8vAAAAAAAA --Apple-Mail=_BE593293-6221-4BA2-9CF3-F134AF1B930C-- From nobody Tue Mar 17 14:32:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EC31A88F8 for ; Tue, 17 Mar 2015 14:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 TWWD69ooLwex for ; Tue, 17 Mar 2015 14:32:27 -0700 (PDT) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C4F1A1B3C for ; Tue, 17 Mar 2015 14:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426627945; bh=1T9CtNqSt24Gewca7fTXjZXh29+wsjP2VOX8XeNeDe4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=IydaJlJKrEI/+1mrS3K2osFAuhySyPMzQPgFLA93QcJniAl7LoC3WUYObGIKYD306U+7WHwMutSeOQOR1C0OE4EUn8CgUHTLwSSYaElwMfWuxrAw2e103c++OyMMmG5ez+R0tCeAWBiX/7c3ufnDsASQlBI6BGEXJzZ1UnSw7UzvXFjp3KGLlMqrzXxz8nkM5IRH2sqdHEuF1PP3EyMrzJRzk6iGAk/L6JCsRVcAazec99jmdou4NObds8z9RtA5pEcuEDk1Vs3QlebhuQlfPK35Hxu9gOCZFu+EpfL9Y2EnqlHV9mkbZTqjzMbIdrGP8qcpedzsOkIbRaSSgylOkg== Received: from [98.139.170.179] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:32:25 -0000 Received: from [98.139.215.254] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:32:25 -0000 Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 21:32:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 699494.51339.bm@omp1067.mail.bf1.yahoo.com X-YMail-OSG: JGkEEK4VM1lb1.r8yGqUkkfL0Czp7rth6DxnNi.iH3MtWEVAWPdrlUBgolPbJzi FQEETnJQkB5RzubI8VzRAyoMACDGXnbkQPBnsAixwokEJq0PnybsJfan2KK7Vk_H.44EeBCJm3Mt LOaL4HgGUblA8Ow21v.yrSe.4a2GGjo1w1YegZfWxSm7KA8o5.qVZoCz8YgEdU6dhaRC2H_x2j5F j27MQNFNErHsthaKhi8Ucn4vJmdlf6tdikPtroek7sPQGK8D8ES8nzoCARKWRca_Fbp1obNfca8S zB__AeB6CWQAk1C0AJGBEO_3sSc65dRO9X8DLeP1p4vBm1x_MXEEruSabdiY86lRsn1nIyk25.Tv U6Gg.qFrj4kXI1keiXw.QCJgJslibkkR4ryLeBgCQW5r7cxD92i_bfe2vLd8uYkhdZjZn32ZPSXt M1Viwrl.QZEfvYYTYLGk3mhWgV3IXMvWuwY1A4s3FDPBn5pf1q8G2KK_nAlE9ve07.Ak6SlHvhxi 0anvmSs01RQhakT2LP0OW_hMdsWqMF5sTw6NnacAbySij4_NPZvOK.AjBSeWbRQ-- Received: by 66.196.80.112; Tue, 17 Mar 2015 21:32:25 +0000 Date: Tue, 17 Mar 2015 21:32:24 +0000 (UTC) From: Bill Mills To: John Bradley Message-ID: <1875922339.168142.1426627944661.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_168141_787655032.1426627944630" Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:32:31 -0000 ------=_Part_168141_787655032.1426627944630 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In practice one of the drawbacks of the Oauth 1.0a tokens was that they wer= e not proxyable and so a connection to the edge then means you have to unwr= ap that and make a new internal token to be usedwhich isn't as good as the = actual user credential.=C2=A0=20 On Tuesday, March 17, 2015 2:26 PM, John Bradley w= rote: =20 PoP tokens need to be presented with a proof the presenter knows the secre= t. =C2=A0That is the same principal as in OAuth 1.0a with needing to show k= nowledge of the "token secret". I don't know what you mean by proxies internally. =C2=A0 If the RS needs an= other token to access a resource it should use the assertion flow and authe= nticate itself to get another token based on the access token.Passing aroun= d a PoP token as a bearer token is insecure/bad. In OAuth 1.0a because of the tight relationship between the "Service Provid= er" and the "Protected Resource" people would be less likely to try it but = because the protected resource knows the "token secret" it could still do l= ots of unexpected bad things. Proxying access tokens is not something RS should do, they need to be excha= nged at a AS for a new AT with the correct rights and optionally binding it= to a new PoP key. John B. On Mar 17, 2015, at 6:14 PM, Bill Mills wrote: Yes. =C2=A0There's still the open question of whether/how PoP tokens can be= proxied internally within a site though. =C2=A0If they can be proxied then= it goes back to unsolved.=20 On Tuesday, March 17, 2015 2:12 PM, John Bradley w= rote: =20 Or by OAuth 2 PoP. =C2=A0 =C2=A0 On Mar 17, 2015, at 6:00 PM, Bill Mills wrote: "Yes but it is custom. =C2=A0People are inventing structured scopes like "a= ud:https://foo.com", and that potentially doesn't solve the security issue = if a client just passes on the scopes it receives in the error response, th= e bad RS just adds a scope for the good RS." This isn't solved by "aud", it is solved by OAuth 1.0a though.... =C2=A0 On Tuesday, March 17, 2015 1:54 PM, John Bradley w= rote: =20 Yes but it is custom. =C2=A0People are inventing structured scopes like "a= ud:https://foo.com", and that potentially doesn't solve the security issue = if a client just passes on the scopes it receives in the error response, th= e bad RS just adds a scope for the good RS. The client then potentially needs to understand the custom structures scope= s of every AS it might deal with. I think that would lead to lots of problems trying to make that a pattern l= ong term. =C2=A0 At teh moment yes you can do it with a scope as long as th= e client and AS both understand what is going on. We added "aud" as a separate parameter for PoP as the token format for diff= erent RS might be different as well as the symmetric =C2=A0pop keys needing= to be encrypted with different keys.Yes we could have invented a special s= cope to carry the audience but a separate parameter was much cleaner. I know some people have started using "aud" as a way to communicate the res= ource when a scope applies to multiple RS but they may take different token= formats JWT vs opaque etc. Brian commented that the "aud" parameter may be useful beyond PoP so we mig= ht want to think about documenting it in it's own mini spec, if I understoo= d him correctly. I think that may not be a bad idea as we are also planning on using it in N= APPS. John B. On Mar 17, 2015, at 5:39 PM, Bill Mills wrote: I don't think it's "overloading scope names" to use them that way. =C2=A0Th= e aud value(s) could as easily be carried in scope as anywhere. =C2=A0Nothi= ng says a scope can't be "https://foo.com", and that Foo.com requires that = scope to be present for a token to be accepted. =C2=A0I would not make it f= oo.com-read-mail for example. If it's more convenient to put it in aud I can accept that, but it's the sa= me functionality and can be implemented in scopes now.=20 On Tuesday, March 17, 2015 12:41 PM, John Bradley = wrote: =20 People have been overloading scope names to create implicit audience. =C2= =A0=C2=A0 The problem is that clients need to know via some magic method that you nee= d to ask for scope "purple" to get write access to RS 2. Having an explicit "aud" parameter gives clients a way to communicate to th= e AS what RS they are asking for a token for.=C2=A0 the security issue is that if a client discovers a API out via some out of = band mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y. =C2=A0 Unfortunately without POP tokens or at-least passing the URI of the RS to t= he AS via "aud", a bad RS could get a legitimate client to give it a token = that can be replayed at a legitimate RS. This was one of the issues that Eran Hammer-Lahav was particularly concerne= d about. =C2=A0 I think I proposed a "aud" parameter to the token endpoint back then as a a= lternative to requiring HMAC tokens, but that got lost in the confusion at = the time. At that time though people were not yet thinking about interoperable OAuth = API, =C2=A0only relatively tightly bound clients that were preconfigured fo= r the API endpoints they were using. In Health and other places we are starting to see standard clients that dis= cover API endpoints and configure themselves based on a users Identity to u= se a arbitrary OAuth AS, moving into federation of AT. That is one of the reasons POP will be important, as it prevents RS from mi= susing federated tokens by presenting them at other RS. The simplest thing to do is have the client say what RS it is trying to acc= ess explicitly (The "aud" parameter), and including an audience in the AT. = =C2=A0to protect against malicious RS. PoP is the step up that also protects against tokens being intercepted and = replayed by another client. John B. On Mar 17, 2015, at 4:10 PM, Bill Mills wrote: This may have been hashed out already and I missed it, but "aud" just becom= es another kind of scope, correct? =20 On Tuesday, March 17, 2015 8:50 AM, John Bradley w= rote: =20 You could do that, but it is probably safer for the AS to know what RS it = can issue tokens for and refuse to issue a token for RS A to a client askin= g for a token with RS X as the aud. John B. On Mar 16, 2015, at 8:27 PM, Dixie Baker wr= ote: The threat that RFC6819 4.6.4 describes is when a client obtains an AT and = then sends it to a counterfeit RS, which then uses the AT to access resourc= es from a legitimate RS, on the end-user's behalf. =C2=A0 The suggested countermeasure is a bit difficult to interpret: =C2=A0"Associ= ate the endpoint URL of the resource server the client talked to with the a= ccess token (e.g., in an audience field) and validate the association at a = legitimate resource server. =C2=A0The endpoint URL validation policy may be= strict (exact match) or more relaxed (e.g., same host). =C2=A0This would r= equire telling the authorization server about the resource server endpoint = URL in the authorization process." =C2=A0 As I read this, the suggestion is to have the client pass the URL of the ba= d RS in the request to the AS (using the audience field). =C2=A0The AS then= would include that RS URL in the AT. =C2=A0Then, when the client passes th= e AT to the bad RS, and it passes it on to the good RS, the good RS will ch= eck the audience field, compare that URL with its own, and refuse the reque= st. =C2=A0 -Dixie Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 11:39 AM, John Bradley wrote: Brian and I were talking about "aud" used as a parameter to the token endpo= int when using a code or refresh token to indicate what RS the resulting AT= will be used at. Sending a audience in the AT wouldn't help prevent the attack being discuss= ed, =C2=A0though it may stop other sorts of attacks if the RS can tell if a= AT was issued for it or another RS. In PoP having the AS check that you are sending the AT to the correct RS is= less important as the AT if stolen can't be used to replay against the rea= l AS. Though depending on the app the bogus RS feeding the app the wrong info may= well be a problem as well. John B. On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = wrote: I don't think putting an aud into an AT will help to prevent counterfeit RS= s (as long as the aud is nit directly derived from the original URL used by= the client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate RS = and just (ab)use it. POP on the contrary helps since the counterfeit RS, in order to send a mess= age to the legitimate RS, needs to produce a new digitally signed message u= sing the correct secret, which it doesn't know. kind regards,Torsten. Am 16.03.2015 um 17:40 schrieb Dixie Baker : Using the "aud" parameter makes sense to me. =C2=A0Good suggestion. Authenticating the client to the RS would not address the counterfeit RS th= reat.=C2=A0 -Dixie =C2=A0 Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 6:43 AM, Brian Campbell wr= ote: We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identi= fy the RS to whom the AT should be issued. It is useful but it's mostly abo= ut getting format/content/etc of the AT correct for the RS rather than it i= s about preventing possible AT leaks. I do think an "aud(iance)" parameter at both token and authorization endpoi= nts would have utility beyond the POP work. So defining it independently mi= ght make sense.=20 On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: In POP key distribution we do introduce a "audiance" parameter to the token= _endpoint.=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distri= bution-01#section-3.1 It would be possible to have a small spec to define using "aud" with bearer= tokens, however that would be undefined behaviour at this point. I don't know of any clients that would try to access a RS server and then b= esed on the error response try and get a access token from the AS specified= in the error. In POP we are trying to both protect agains that attack and more common one= s like doing a MiM to intercept the AT or the RS being hacked and leaking t= he token. Using "aud" with bearer tokens would be useful, but probably won't stop the= majority of possible AT leaks. John B. On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = wrote: Hi Josh, =20 I'm not aware of a common practice to use such a parameter. The WG is inst= ead heading towards authenticated requests to the resource server (see http= s://tools.ietf.org/html/rfc6819#section-5.4.2).=20 =20 Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-ar= chitecture and further drafts on this topic. =20 kind regards, Torsten. =20 Am 03.03.2015 um 18:27 schrieb Josh Mandel: =20 Hi All,=20 In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource = Server"), RFC6819 describes a threat where a counterfeit resource server tr= icks a client into obtaining and sharing an access token from a legitimate = authorization server. One of the proposed mitigations involves: "telling th= e authorization server about the resource server endpoint URL in the author= ization process."=20 In other words, this mitigation would ask the client to pass an additiona= l parameter when redirecting to the Authorization server's "authorize" URL,= effectively something like:=20 https://auth-server/authorize? response_type=3Dcode& client_id=3D123& st= ate=3D456& scope=3Dread-all& redirect_uri=3Dhttps://app-server/after-auth& resourc= e_server_that_told_me_to_authorize_here=3Dhttps://attacker.com =20 (And if the authorization server saw a value it didn't like in the final = parameter, it would reject the request.)=20 This is obviously not appropriate in every authorization scenario, but it= is useful anytime there's a discovery process by which apps learn about au= thorization servers from resource servers. Since it's something of a common= need, I wanted to see if there was any common practice in how to name this= parameter, or whether it's worth registering a standard extension at=C2=A0= http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (= I don't see one there now -- possibly I'm just missing it.)=20 If so, what should it be called? The name I used in the example above is = a bit verbose :-)=20 Best,=20 =C2=A0 Josh =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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 ------=_Part_168141_787655032.1426627944630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In = practice one of the drawbacks of the Oauth 1.0a tokens was that they were n= ot proxyable and so a connection to the edge then means you have to unwrap = that and make a new internal token to be usedwhich isn't as good as the act= ual user credential. 



=
On Tuesday, March 1= 7, 2015 2:26 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
 =


<= div>PoP tokens need to be presented with a proof the presenter knows the se= cret.  That is the same principal as in OAuth 1.0a with needing to sho= w knowledge of the "token secret".

I don't k= now what you mean by proxies internally.   If the RS needs another tok= en to access a resource it should use the assertion flow and authenticate i= tself to get another token based on the access token.
Passing around a PoP token as a bearer token is insecure/bad.<= /div>

In OAuth 1.0a because of the tight rel= ationship between the "Service Provider" and the "Protected Resource" peopl= e would be less likely to try it but because the protected resource knows t= he "token secret" it could still do lots of unexpected bad things.

=
Proxying access tokens is not something RS sho= uld do, they need to be exchanged at a AS for a new AT with the correct rig= hts and optionally binding it to a new PoP key.

John B.



On Mar 17, 2015, at 6:14 PM, Bill Mills <wm= ills_92105@yahoo.com> wrote:

Yes.  There's still= the open question of whether/how PoP tokens can be proxied internally with= in a site though.  If they can be proxied then it goes back to unsolve= d.



On Tuesday, March 17, 2015 2= :12 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


Or by OAuth 2 PoP.    


On Mar 17, 2015, at 6:00 PM, Bill Mills <wmills_92105= @yahoo.com> wrote:

"Yes but it is custom.  People are inventing structured scopes like = "aud:https://foo.= com", and that potential= ly doesn't solve the security issue if a client just passes on the scopes i= t receives in the error response, the bad RS just adds a scope for the good= RS."

=
This isn't= solved by "aud", it is solved by OAuth 1.0a though....
=
 



= On Tuesday, March= 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


Yes but it is custom.  People ar= e inventing structured scopes like "aud:https://foo.com", and that potentially doesn't solve the security issue if a = client just passes on the scopes it receives in the error response, the bad= RS just adds a scope for the good RS.

The c= lient then potentially needs to understand the custom structures scopes of = every AS it might deal with.

I think t= hat would lead to lots of problems trying to make that a pattern long term.=   At teh moment yes you can do it with a scope as long as the client = and AS both understand what is going on.
=

We added "aud" as a separate parameter for PoP as the token format fo= r different RS might be different as well as the symmetric  pop keys n= eeding to be encrypted with different keys.
Yes we could have invented a special scope to carry the audience but a s= eparate parameter was much cleaner.

I = know some people have started using "aud" as a way to communicate the resou= rce when a scope applies to multiple RS but they may take different token f= ormats JWT vs opaque etc.

Brian commen= ted that the "aud" parameter may be useful beyond PoP so we might want to t= hink about documenting it in it's own mini spec, if I understood him correc= tly.

I think that may not be a bad ide= a as we are also planning on using it in NAPPS.

John B.

<= blockquote class=3D"yiv8943908410" type=3D"cite">
On Mar 17, 2015, at 5:39 PM, Bill Mills <wmills_92105@yahoo.c= om> wrote:

<= div class=3D"yiv8943908410" style=3D"background-color:rgb(255, 255, 255);fo= nt-family:HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande= ', sans-serif;font-size:12px;">
I don't think it's "overloading scope names" to = use them that way.  The aud value(s) could as easily be carried in sco= pe as anywhere.  Nothing says a scope can't be "https://foo.com", and that Foo.com= requires that scope to be present for a token to be accepted.  I woul= d not make it foo.com-read-mail for example.=

If = it's more convenient to put it in aud I can accept that, but it's the same = functionality and can be implemented in scopes now.



On Tuesday, March 17, 2015 12:41 PM, John Bradley <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv8943908410" ymailto=3D"mailto= :ve7jtb@ve7jtb.com" target=3D"_blank" href=3D"mailto:ve7jtb@ve7jtb.com">ve7= jtb@ve7jtb.com> wrote:


P= eople have been overloading scope names to create implicit audience.  =  

The problem is that clients need to k= now via some magic method that you need to ask for scope "purple" to get wr= ite access to RS 2.

Having an explicit "aud"= parameter gives clients a way to communicate to the AS what RS they are as= king for a token for. 

the security issue is that if a client discovers= a API out via some out of band mechanism the OAuth error code can tell the= client go to AS X and ask for Scope Y.  

Unfortunately without POP tokens or at-least passing the URI of th= e RS to the AS via "aud", a bad RS could get a legitimate client to give it= a token that can be replayed at a legitimate RS.

This was one of the issues that Eran Hammer-Lahav was particula= rly concerned about.  

I think I = proposed a "aud" parameter to the token endpoint back then as a alternative= to requiring HMAC tokens, but that got lost in the confusion at the time.<= /div>

At that time though people were not ye= t thinking about interoperable OAuth API,  only relatively tightly bou= nd clients that were preconfigured for the API endpoints they were using.

In Health and other places we are start= ing to see standard clients that discover API endpoints and configure thems= elves based on a users Identity to use a arbitrary OAuth AS, moving into fe= deration of AT.

That is one of the re= asons POP will be important, as it prevents RS from misusing federated toke= ns by presenting them at other RS.

The= simplest thing to do is have the client say what RS it is trying to access= explicitly (The "aud" parameter), and including an audience in the AT. &nb= sp;to protect against malicious RS.

Po= P is the step up that also protects against tokens being intercepted and re= played by another client.

John B.

=
On Mar 17, 20= 15, at 4:10 PM, Bill Mills <wmills_92105@yahoo.com> wrote= :

=
This may hav= e been hashed out already and I missed it, but "aud" just becomes another k= ind of scope, correct?




On Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:


You could do that, but it is probably safer for = the AS to know what RS it can issue tokens for and refuse to issue a token = for RS A to a client asking for a token with RS X as the aud.

John B.
<= div class=3D"yiv8943908410yqt4013611375" id=3D"yiv8943908410yqt73071">
<= div class=3D"yiv8943908410">On Mar 16, 2015, at 8:27 PM, Dixie Baker <Dixie.Baker@martin-blanck.com> wrote:

Th= e threat that RFC6819 4.6.4 describes is when a client obtains an AT and th= en sends it to a counterfeit RS, which then uses the AT to access resources= from a legitimate RS, on the end-user's behalf.  

The suggested countermeasure is a bit difficult to interpret: &= nbsp;"Associate the endpoint URL of the resource server the client talked t= o with the access token (e.g., in an audience field) and validate the assoc= iation at a legitimate resource server.  The endpoint URL validation p= olicy may be strict (exact match) or more relaxed (e.g., same host).  = This would require telling the authorization server about the resource serv= er endpoint URL in the authorization process."  

As I read this, the suggestion is to have the client pass t= he URL of the bad RS in the request to the AS (using the audience field). &= nbsp;The AS then would include that RS URL in the AT.  Then, when the = client passes the AT to the bad RS, and it passes it on to the good RS, the= good RS will check the audience field, compare that URL with its own, and = refuse the request.  

-Dixie



Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 11:39 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:

<= div class=3D"yiv8943908410" style=3D"word-wrap:break-word;">Brian and I wer= e talking about "aud" used as a parameter to the token endpoint when using = a code or refresh token to indicate what RS the resulting AT will be used a= t.

<= /div>
Sending a audience in the AT wouldn't hel= p prevent the attack being discussed,  though it may stop other sorts = of attacks if the RS can tell if a AT was issued for it or another RS.

In PoP having the AS check that you are se= nding the AT to the correct RS is less important as the AT if stolen can't = be used to replay against the real AS.
Though depending on the app the bogus RS feeding the app the wrong info ma= y well be a problem as well.

John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodd= erstedt <torsten@lodderstedt.net> wrote:

I don't= think putting an aud into an AT will help to prevent counterfeit RSs (as l= ong as the aud is nit directly derived from the original URL used by the cl= ient to invoke the counterfeit RS. as long as the aud is a symbolic name of= any kind, the counterfeit RS will accept ATs for the legitimate RS and jus= t (ab)use it.

POP on the contrary help= s since the counterfeit RS, in order to send a message to the legitimate RS= , needs to produce a new digitally signed message using the correct secret,= which it doesn't know.

kind regards,<= /div>
Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "au= d" parameter makes sense to me.  Good suggestion.

Authenticating the client to the RS would not address the counte= rfeit RS threat. 

-Dixie

=
 
Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv8943908410" ymailto=3D"mailto= :bcampbell@pingidentity.com" target=3D"_blank" href=3D"mailto:bcampbell@pin= gidentity.com">bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 and bea= rer tokens to help identify the RS to whom the AT should be issued. It is u= seful but it's mostly about getting format/content/etc of the AT correct fo= r the RS rather than it is about preventing possible AT leaks.

I do think an "aud(iance)" parameter at both token and authorization en= dpoints would have utility beyond the POP work. So defining it independentl= y might make sense.

On Sun, Mar 15, 2015 at 11:34 AM,= John Bradley <ve7jtb@ve7jtb.com= > wrote:
In POP key distribution we do introduce a "audiance" p= arameter to the token_endpoint. https://tools.ietf.or= g/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1

It would be possible to have a small spec to define u= sing "aud" with bearer tokens, however that would be undefined behaviour at= this point.

I don't know of any clien= ts that would try to access a RS server and then besed on the error respons= e try and get a access token from the AS specified in the error.

In POP we are trying to both protect agains that= attack and more common ones like doing a MiM to intercept the AT or the RS= being hacked and leaking the token.

U= sing "aud" with bearer tokens would be useful, but probably won't stop the = majority of possible AT leaks.

John B= .


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt &= lt;torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Toke= n Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would = ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_= server_that_told_me_to_authorize_here=3Dht= tps://attacker.com

(And if the authorization server saw a= value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in e= very authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-p= arameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The n= ame I used in the example above is a bit verbose :-)

Best,

  Josh


________________________________________=
_______
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org=
/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oau= th
<= br clear=3D"none" class=3D"yiv8943908410">

_________________________________________= ______
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth



<= /div>

=
<= /div>

=
<= /div>


<= /div>

------=_Part_168141_787655032.1426627944630-- From nobody Tue Mar 17 14:40:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8D01A890A for ; Tue, 17 Mar 2015 14:40: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 1Rjkzo0qMocV for ; Tue, 17 Mar 2015 14:40:49 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (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 C2DEA1A1B6B for ; Tue, 17 Mar 2015 14:40:48 -0700 (PDT) Received: by qcaz10 with SMTP id z10so22216659qca.1 for ; Tue, 17 Mar 2015 14:40:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=tqXNNXWksrnPfsq4NUjQTMyOVfj/ifkUMGggLCWlEOc=; b=NPUeU19hBPSPJ16xhOpMFfLZxElC8grznSckjl9AkQIKBPu4vEPdlB/PiIjla0jGYO oqWFhzQ5MQd5W5HCYX/Pwg8Ua/vEu1IZ7xjwVuLGhXpUr/NnWmfyZBGjt3NY79VpotFD dBbbfSLJ7mFF03Tint5sL67pCycwFmiU5/F0PXoticcYhpS0/7e6eKKRKfPH1mA5vUft jmJd9OMCabt44f178vveEfRH6rI17bYJlHl0wTSzgUKmTEillq9mQ7q1k+kPLhk/1Chb QEdf8LMxnkn4ZpFjRUFjY34kgfcHLQuglkID7qb5NCV/10DGAQu7Jg8f7pxzpKkbA/ie EaqQ== X-Gm-Message-State: ALoCoQkW0e+LOyB7k+eajWTmc/6W9RcfbUVD64cbt4gZ3muK2p8zUwJ9PK0Th/3ORDneylr4tDM+ X-Received: by 10.55.31.97 with SMTP id f94mr89259798qkf.10.1426628447880; Tue, 17 Mar 2015 14:40:47 -0700 (PDT) Received: from [192.168.8.100] ([181.202.4.92]) by mx.google.com with ESMTPSA id o19sm10475090qkh.25.2015.03.17.14.40.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 14:40:47 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D20341B3-6929-4200-BDA0-770C4B3D969F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <1875922339.168142.1426627944661.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Mar 2015 18:40:42 -0300 Message-Id: References: <1875922339.168142.1426627944661.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:40:55 -0000 --Apple-Mail=_D20341B3-6929-4200-BDA0-770C4B3D969F Content-Type: multipart/alternative; boundary="Apple-Mail=_651E672A-D2D2-49A5-9979-DDAEF4369D5E" --Apple-Mail=_651E672A-D2D2-49A5-9979-DDAEF4369D5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is fun:) I might ask what part of a OAuth 1.0a token is the user credential. = That is a slippery idea in itself. The token is a reference to some = notion of identity (in some cases) that needs to be dereferenced anyway. So in the same way a POP JWT access token in OAuth 2 that may indeed = contain claims about the subject would need to be exchanged at a AS for = a new token containing claims about the subject and the new presenter, = or depending on the security model it could be included directly in a = new self signed AT. =46rom a enterprise policy point of view having a REST like STS = functionality is I think the right long term answer. John B. > On Mar 17, 2015, at 6:32 PM, Bill Mills = wrote: >=20 > In practice one of the drawbacks of the Oauth 1.0a tokens was that = they were not proxyable and so a connection to the edge then means you = have to unwrap that and make a new internal token to be usedwhich isn't = as good as the actual user credential.=20 >=20 >=20 >=20 > On Tuesday, March 17, 2015 2:26 PM, John Bradley = wrote: >=20 >=20 > PoP tokens need to be presented with a proof the presenter knows the = secret. That is the same principal as in OAuth 1.0a with needing to = show knowledge of the "token secret". >=20 > I don't know what you mean by proxies internally. If the RS needs = another token to access a resource it should use the assertion flow and = authenticate itself to get another token based on the access token. > Passing around a PoP token as a bearer token is insecure/bad. >=20 > In OAuth 1.0a because of the tight relationship between the "Service = Provider" and the "Protected Resource" people would be less likely to = try it but because the protected resource knows the "token secret" it = could still do lots of unexpected bad things. >=20 > Proxying access tokens is not something RS should do, they need to be = exchanged at a AS for a new AT with the correct rights and optionally = binding it to a new PoP key. >=20 > John B. >=20 >=20 >=20 > On Mar 17, 2015, at 6:14 PM, Bill Mills > wrote: >>=20 >> Yes. There's still the open question of whether/how PoP tokens can = be proxied internally within a site though. If they can be proxied then = it goes back to unsolved. >>=20 >>=20 >>=20 >> On Tuesday, March 17, 2015 2:12 PM, John Bradley > wrote: >>=20 >>=20 >> Or by OAuth 2 PoP. =20 >>=20 >>=20 >>> On Mar 17, 2015, at 6:00 PM, Bill Mills > wrote: >>>=20 >>> "Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS." >>>=20 >>> This isn't solved by "aud", it is solved by OAuth 1.0a though.... >>> =20 >>>=20 >>>=20 >>>=20 >>> On Tuesday, March 17, 2015 1:54 PM, John Bradley > wrote: >>>=20 >>>=20 >>> Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS. >>>=20 >>> The client then potentially needs to understand the custom = structures scopes of every AS it might deal with. >>>=20 >>> I think that would lead to lots of problems trying to make that a = pattern long term. At teh moment yes you can do it with a scope as = long as the client and AS both understand what is going on. >>>=20 >>>=20 >>> We added "aud" as a separate parameter for PoP as the token format = for different RS might be different as well as the symmetric pop keys = needing to be encrypted with different keys. >>> Yes we could have invented a special scope to carry the audience but = a separate parameter was much cleaner. >>>=20 >>> I know some people have started using "aud" as a way to communicate = the resource when a scope applies to multiple RS but they may take = different token formats JWT vs opaque etc. >>>=20 >>> Brian commented that the "aud" parameter may be useful beyond PoP so = we might want to think about documenting it in it's own mini spec, if I = understood him correctly. >>>=20 >>> I think that may not be a bad idea as we are also planning on using = it in NAPPS. >>>=20 >>> John B. >>>=20 >>>> On Mar 17, 2015, at 5:39 PM, Bill Mills > wrote: >>>>=20 >>>> I don't think it's "overloading scope names" to use them that way. = The aud value(s) could as easily be carried in scope as anywhere. = Nothing says a scope can't be "https://foo.com ", and = that Foo.com requires that scope to be present for a = token to be accepted. I would not make it foo.com = -read-mail for example. >>>>=20 >>>> If it's more convenient to put it in aud I can accept that, but = it's the same functionality and can be implemented in scopes now. >>>>=20 >>>>=20 >>>>=20 >>>> On Tuesday, March 17, 2015 12:41 PM, John Bradley = > wrote: >>>>=20 >>>>=20 >>>> People have been overloading scope names to create implicit = audience. =20 >>>>=20 >>>> The problem is that clients need to know via some magic method that = you need to ask for scope "purple" to get write access to RS 2. >>>>=20 >>>> Having an explicit "aud" parameter gives clients a way to = communicate to the AS what RS they are asking for a token for.=20 >>>>=20 >>>> the security issue is that if a client discovers a API out via some = out of band mechanism the OAuth error code can tell the client go to AS = X and ask for Scope Y. =20 >>>>=20 >>>> Unfortunately without POP tokens or at-least passing the URI of the = RS to the AS via "aud", a bad RS could get a legitimate client to give = it a token that can be replayed at a legitimate RS. >>>>=20 >>>> This was one of the issues that Eran Hammer-Lahav was particularly = concerned about. =20 >>>>=20 >>>> I think I proposed a "aud" parameter to the token endpoint back = then as a alternative to requiring HMAC tokens, but that got lost in the = confusion at the time. >>>>=20 >>>> At that time though people were not yet thinking about = interoperable OAuth API, only relatively tightly bound clients that = were preconfigured for the API endpoints they were using. >>>>=20 >>>> In Health and other places we are starting to see standard clients = that discover API endpoints and configure themselves based on a users = Identity to use a arbitrary OAuth AS, moving into federation of AT. >>>>=20 >>>> That is one of the reasons POP will be important, as it prevents RS = from misusing federated tokens by presenting them at other RS. >>>>=20 >>>> The simplest thing to do is have the client say what RS it is = trying to access explicitly (The "aud" parameter), and including an = audience in the AT. to protect against malicious RS. >>>>=20 >>>> PoP is the step up that also protects against tokens being = intercepted and replayed by another client. >>>>=20 >>>> John B. >>>>=20 >>>>> On Mar 17, 2015, at 4:10 PM, Bill Mills > wrote: >>>>>=20 >>>>> This may have been hashed out already and I missed it, but "aud" = just becomes another kind of scope, correct? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tuesday, March 17, 2015 8:50 AM, John Bradley = > wrote: >>>>>=20 >>>>>=20 >>>>> You could do that, but it is probably safer for the AS to know = what RS it can issue tokens for and refuse to issue a token for RS A to = a client asking for a token with RS X as the aud. >>>>>=20 >>>>> John B. >>>>>> On Mar 16, 2015, at 8:27 PM, Dixie Baker = > = wrote: >>>>>>=20 >>>>>=20 >>>>> The threat that RFC6819 4.6.4 describes is when a client obtains = an AT and then sends it to a counterfeit RS, which then uses the AT to = access resources from a legitimate RS, on the end-user's behalf. =20 >>>>>=20 >>>>> The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." =20 >>>>>=20 >>>>> As I read this, the suggestion is to have the client pass the URL = of the bad RS in the request to the AS (using the audience field). The = AS then would include that RS URL in the AT. Then, when the client = passes the AT to the bad RS, and it passes it on to the good RS, the = good RS will check the audience field, compare that URL with its own, = and refuse the request. =20 >>>>>=20 >>>>> -Dixie >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Dixie B. Baker, Ph.D. >>>>> Senior Partner >>>>> Martin, Blanck and Associates >>>>> Office (Redondo Beach, CA): 310-791-9671 >>>>> Mobile: 310-279-2579 >>>>>=20 >>>>> On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >>>>>=20 >>>>>=20 >>>>> Brian and I were talking about "aud" used as a parameter to the = token endpoint when using a code or refresh token to indicate what RS = the resulting AT will be used at. >>>>>=20 >>>>> Sending a audience in the AT wouldn't help prevent the attack = being discussed, though it may stop other sorts of attacks if the RS = can tell if a AT was issued for it or another RS. >>>>>=20 >>>>> In PoP having the AS check that you are sending the AT to the = correct RS is less important as the AT if stolen can't be used to replay = against the real AS. >>>>>=20 >>>>> Though depending on the app the bogus RS feeding the app the wrong = info may well be a problem as well. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>>>>>=20 >>>>>=20 >>>>> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>>>>=20 >>>>> POP on the contrary helps since the counterfeit RS, in order to = send a message to the legitimate RS, needs to produce a new digitally = signed message using the correct secret, which it doesn't know. >>>>>=20 >>>>> kind regards, >>>>> Torsten. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>>>>=20 >>>>>=20 >>>>> Using the "aud" parameter makes sense to me. Good suggestion. >>>>>=20 >>>>> Authenticating the client to the RS would not address the = counterfeit RS threat.=20 >>>>>=20 >>>>> -Dixie >>>>>=20 >>>>> =20 >>>>> Dixie B. Baker, Ph.D. >>>>> Senior Partner >>>>> Martin, Blanck and Associates >>>>> Office (Redondo Beach, CA): 310-791-9671 >>>>> Mobile: 310-279-2579 >>>>>=20 >>>>> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>>>>=20 >>>>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to = help identify the RS to whom the AT should be issued. It is useful but = it's mostly about getting format/content/etc of the AT correct for the = RS rather than it is about preventing possible AT leaks. >>>>>>=20 >>>>>> I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So = defining it independently might make sense.=20 >>>>>>=20 >>>>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley > wrote: >>>>>> In POP key distribution we do introduce a "audiance" parameter to = the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>>>>=20 >>>>>> It would be possible to have a small spec to define using "aud" = with bearer tokens, however that would be undefined behaviour at this = point. >>>>>>=20 >>>>>> I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the = AS specified in the error. >>>>>>=20 >>>>>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>>>>=20 >>>>>> Using "aud" with bearer tokens would be useful, but probably = won't stop the majority of possible AT leaks. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>>>>=20 >>>>>>> Hi Josh, >>>>>>>=20 >>>>>>> I'm not aware of a common practice to use such a parameter. The = WG is instead heading towards authenticated requests to the resource = server (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>>>>=20 >>>>>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>>>>=20 >>>>>>> kind regards, >>>>>>> Torsten. >>>>>>>=20 >>>>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit = Resource Server"), RFC6819 describes a threat where a counterfeit = resource server tricks a client into obtaining and sharing an access = token from a legitimate authorization server. One of the proposed = mitigations involves: "telling the authorization server about the = resource server endpoint URL in the authorization process." >>>>>>>>=20 >>>>>>>> In other words, this mitigation would ask the client to pass an = additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>>>>=20 >>>>>>>> https://auth-server/authorize ? >>>>>>>> response_type=3Dcode& >>>>>>>> client_id=3D123& >>>>>>>> state=3D456& >>>>>>>> scope=3Dread-all& >>>>>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>>>>=20 >>>>>>>> (And if the authorization server saw a value it didn't like in = the final parameter, it would reject the request.) >>>>>>>>=20 >>>>>>>> This is obviously not appropriate in every authorization = scenario, but it is useful anytime there's a discovery process by which = apps learn about authorization servers from resource servers. Since it's = something of a common need, I wanted to see if there was any common = practice in how to name this parameter, or whether it's worth = registering a standard extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>>>>=20 >>>>>>>> If so, what should it be called? The name I used in the example = above is a bit verbose :-) >>>>>>>>=20 >>>>>>>> Best, >>>>>>>>=20 >>>>>>>> Josh >>>>>>>>=20 >>>>>>>>=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 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_651E672A-D2D2-49A5-9979-DDAEF4369D5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is fun:)

I might ask what part of a OAuth 1.0a token is the user = credential.   That is a slippery idea in itself.  The token is = a reference to some notion of identity (in some cases) that needs to be = dereferenced anyway.

So in the same way a POP JWT access token in OAuth 2 that may = indeed contain claims about the subject would need to be exchanged at a = AS for a new token containing claims about the subject and the new = presenter, or depending on the security model it could be included = directly in a new self signed AT.

=46rom a enterprise policy point of = view having a REST like STS functionality is I think the right long term = answer.

John = B.



On Mar 17, 2015, at 6:32 PM, = Bill Mills <wmills_92105@yahoo.com> wrote:

In practice one of = the drawbacks of the Oauth 1.0a tokens was that they were not proxyable = and so a connection to the edge then means you have to unwrap that and = make a new internal token to be usedwhich isn't as good as the actual = user credential. 



On Tuesday, = March 17, 2015 2:26 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


=
PoP tokens need to be presented with a proof the presenter = knows the secret.  That is the same principal as in OAuth 1.0a with = needing to show knowledge of the "token secret".

I don't know = what you mean by proxies internally.   If the RS needs another = token to access a resource it should use the assertion flow and = authenticate itself to get another token based on the access = token.
Passing around a PoP token as a = bearer token is insecure/bad.

In OAuth 1.0a because of the tight relationship = between the "Service Provider" and the "Protected Resource" people would = be less likely to try it but because the protected resource knows the = "token secret" it could still do lots of unexpected bad = things.

Proxying = access tokens is not something RS should do, they need to be exchanged = at a AS for a new AT with the correct rights and optionally binding it = to a new PoP key.

John B.



On Mar 17, 2015, at 6:14 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

Yes.  There's = still the open question of whether/how PoP tokens can be proxied = internally within a site though.  If they can be proxied then it = goes back to unsolved.



On = Tuesday, March 17, 2015 2:12 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
Or by OAuth 2 PoP. =    


On Mar 17, 2015, at 6:00 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

"Yes but it is custom. =  People are inventing structured scopes like "aud:https://foo.com", and that potentially = doesn't solve the security issue if a client just passes on the scopes = it receives in the error response, the bad RS just adds a scope for the = good RS."

This isn't solved by "aud", it is solved by = OAuth 1.0a though....
 


On = Tuesday, March 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
Yes but it is custom. =  People are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS.

The client = then potentially needs to understand the custom structures scopes of = every AS it might deal with.

I think that would lead to lots of problems = trying to make that a pattern long term.   At teh moment yes you = can do it with a scope as long as the client and AS both understand what = is going on.


We added "aud" as a separate parameter for PoP = as the token format for different RS might be different as well as the = symmetric  pop keys needing to be encrypted with different = keys.
Yes we could have invented a = special scope to carry the audience but a separate parameter was much = cleaner.

I know some = people have started using "aud" as a way to communicate the resource = when a scope applies to multiple RS but they may take different token = formats JWT vs opaque etc.

Brian commented that the "aud" parameter may be = useful beyond PoP so we might want to think about documenting it in it's = own mini spec, if I understood him correctly.

I think that = may not be a bad idea as we are also planning on using it in = NAPPS.

John = B.

On Mar 17, 2015, at 5:39 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

I don't think it's = "overloading scope names" to use them that way.  The aud value(s) = could as easily be carried in scope as anywhere.  Nothing says a = scope can't be "https://foo.com", and = that Foo.com requires that = scope to be present for a token to be accepted.  I would not make = it foo.com-read-mail for = example.

If it's more = convenient to put it in aud I can accept that, but it's the same = functionality and can be implemented in scopes now.



On = Tuesday, March 17, 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
People have been = overloading scope names to create implicit audience.   

The problem = is that clients need to know via some magic method that you need to ask = for scope "purple" to get write access to RS 2.

Having an = explicit "aud" parameter gives clients a way to communicate to the AS = what RS they are asking for a token for. 

the security = issue is that if a client discovers a API out via some out of band = mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y.  

Unfortunately = without POP tokens or at-least passing the URI of the RS to the AS via = "aud", a bad RS could get a legitimate client to give it a token that = can be replayed at a legitimate RS.

This was one of the issues that Eran = Hammer-Lahav was particularly concerned about.  

I think I = proposed a "aud" parameter to the token endpoint back then as a = alternative to requiring HMAC tokens, but that got lost in the confusion = at the time.

At that time = though people were not yet thinking about interoperable OAuth API, =  only relatively tightly bound clients that were preconfigured for = the API endpoints they were using.

In Health and other places we are starting to = see standard clients that discover API endpoints and configure = themselves based on a users Identity to use a arbitrary OAuth AS, moving = into federation of AT.

That is one of the reasons POP will be = important, as it prevents RS from misusing federated tokens by = presenting them at other RS.

The simplest thing to do is have the client say = what RS it is trying to access explicitly (The "aud" parameter), and = including an audience in the AT.  to protect against malicious = RS.

PoP is the = step up that also protects against tokens being intercepted and replayed = by another client.

John = B.

On Mar 17, 2015, at 4:10 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

This may have been hashed out already and I = missed it, but "aud" just becomes another kind of scope, = correct?




On = Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
You could do that, but it is probably safer for = the AS to know what RS it can issue tokens for and refuse to issue a = token for RS A to a client asking for a token with RS X as the = aud.

John B.
On Mar 16, 2015, at 8:27 PM, = Dixie Baker <Dixie.Baker@martin-blanck.co= m> wrote:

The threat that RFC6819 4.6.4 describes = is when a client obtains an AT and then sends it to a counterfeit RS, = which then uses the AT to access resources from a legitimate RS, on the = end-user's behalf.  

The suggested = countermeasure is a bit difficult to interpret:  "Associate the = endpoint URL of the resource server the client talked to with the access = token (e.g., in an audience field) and validate the association at a = legitimate resource server.  The endpoint URL validation policy may = be strict (exact match) or more relaxed (e.g., same host).  This = would require telling the authorization server about the resource server = endpoint URL in the authorization process."  

As I read = this, the suggestion is to have the client pass the URL of the bad RS in = the request to the AS (using the audience field).  The AS then = would include that RS URL in the AT.  Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request.  

-Dixie



Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 11:39 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Brian and I were talking about "aud" = used as a parameter to the token endpoint when using a code or refresh = token to indicate what RS the resulting AT will be used at.

Sending a = audience in the AT wouldn't help prevent the attack being discussed, =  though it may stop other sorts of attacks if the RS can tell if a = AT was issued for it or another RS.

In PoP having the AS check that you are sending = the AT to the correct RS is less important as the AT if stolen can't be = used to replay against the real AS.

Though depending on the app the bogus RS feeding = the app the wrong info may well be a problem as well.

John = B.

On = Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

I don't think putting an aud into an AT will = help to prevent counterfeit RSs (as long as the aud is nit directly = derived from the original URL used by the client to invoke the = counterfeit RS. as long as the aud is a symbolic name of any kind, the = counterfeit RS will accept ATs for the legitimate RS and just (ab)use = it.

POP on the = contrary helps since the counterfeit RS, in order to send a message to = the legitimate RS, needs to produce a new digitally signed message using = the correct secret, which it doesn't know.

kind = regards,
Torsten.



Am = 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.co= m>:

Using the "aud" parameter makes sense to me. =  Good suggestion.

Authenticating = the client to the RS would not address the counterfeit RS = threat. 

-Dixie

 
Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 6:43 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

We've used "aud" (optionally) = with OAuth 2 and bearer tokens to help identify the RS to whom the AT = should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I= do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:
In POP key = distribution we do introduce a "audiance" parameter to the = token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distr= ibution-01#section-3.1

It would be = possible to have a small spec to define using "aud" with bearer tokens, = however that would be undefined behaviour at this point.

I don't know = of any clients that would try to access a RS server and then besed on = the error response try and get a access token from the AS specified in = the error.

In POP we are = trying to both protect agains that attack and more common ones like = doing a MiM to intercept the AT or the RS being hacked and leaking the = token.

Using "aud" = with bearer tokens would be useful, but probably won't stop the majority = of possible AT leaks.

John = B.


On Mar 15, 2015, at 2:18 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.i= etf.org/html/rfc6819#section-5.4.2).

Please take a look onto http= ://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access = Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation = would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?<= /div>
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&= amp;
resource_server_that_told_me_to_authorize_here=3D<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv8943908410" = target=3D"_blank" = href=3D"https://attacker.com/">https://attacker.com

(And if the authorization server = saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate = in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.x= html . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? = The name I used in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


=



=



=



=



=

= --Apple-Mail=_651E672A-D2D2-49A5-9979-DDAEF4369D5E-- --Apple-Mail=_D20341B3-6929-4200-BDA0-770C4B3D969F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTcyMTQwNDJaMCMGCSqGSIb3DQEJBDEWBBQU9WAJHiZOmp/r9tshdQ0h hUyTEDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBj0C8bzLDmIEC5g6ChF15inF9p6XrxP28MNfCUZTqWjMTQ8AIplDeo mT8JgVkM6MYwEzEwAGJQahfo5QFhCsjk6WjUXe1diqROgzQrs4MNaqyeI9tTnPCX+99fIuaqkgBT VLGYBK8wwLmlgTxrO60a94Uy3ZHsf7j31m3CeVBdVyRHEYI3JD1JyHBKdI26P1oJe4shMWdHaMiG R8hK2qWHcjxD0XYplggMCJryK1UCQX0u7hE6k5KN/SqeA43aEe1fgs9HpmEX+vfN2uWVd19zi+oo 9RVuWUGBR7Xc5zR4CQvFdGvuCbuV4vZxYZCnn1bcLnbezTbhdarMlft+Q4AvAAAAAAAA --Apple-Mail=_D20341B3-6929-4200-BDA0-770C4B3D969F-- From nobody Tue Mar 17 16:01:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2431A1B95 for ; Tue, 17 Mar 2015 16:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Aqyk4QoBFSbd for ; Tue, 17 Mar 2015 16:01:44 -0700 (PDT) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD1D1A1B39 for ; Tue, 17 Mar 2015 16:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426633303; bh=f2GG8TB7qmokq8wfzRJiAfwHWU1ViQ9zw5kFjmg3vg0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=gIjFXd/bYEMkyJ3EPfzV+ufEltX/+mYNSZlkqyGPoTeqgIOK7hInLVI0fyu8upGkFN7OE9x8AK6TaMlK4F3oHUUNRD+/qLdHui9TXtA0Xc1U0iWrzu/ftNJwzHtfOhfCab8SGX89bPyr99y9d3nbz8DZvNbLulk4EixweVxwvd2YJrhE7z1vmDACNyoMGOgyuMSsGjD9ssxjwnQpP5dD2LugciM35mByoMy6y+C3Mv6QlYF9Ea9VWx7XUZPcImiJ9SOqcdPu+URx+PpIg8uv+wBY9HHWOGUn+baljmLonRq1CXRZlaXR20c1ACDmzYdmM/q6NCfwozYyC2zdKwgYZw== Received: from [66.196.81.172] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 23:01:43 -0000 Received: from [98.139.212.196] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 23:01:43 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 23:01:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 531360.31012.bm@omp1005.mail.bf1.yahoo.com X-YMail-OSG: cHpesvsVM1nZnnEbJ2iBBMRdKRKGhorgNS7d4i50frY81KtGbDy4ESRil2BvPmE NzRWF7DC8DAOTirskx83sxDJ.F2W..DEA6dzxwIaW0WWWqRfrtkTncTICFPEMlJL05D9dmFKP4is E8XURyBUV9wCCML6LeamP5JufT7Np8.pmsGO18oEiCyE0vDVHvp91FIL2pGe6CreFiuK.HAGuPK7 d_Fkmj8pVpHe5YHc5dKGnq9N3jcMz4x60bik7M7SleJ4xPMoBkeTYkSrpq_i4I6Se6p49lNmIxfi aTo0TwjTNiUfHTAeyawdkiZ7_ubv2YvqShF5ss9ex4qFnfcHrGktrQn5aWxV_tpaDMeai12WzFFm u.4SbqB3yiMyBS7VE0LSru9b9kC_thP4xWanQORTlcU9bDttEFyR.679678LySGK1srosQxIbqqY fw8wAJTgs_JgMSz8glvJ6p_pXryV02oCr23dBghCmml7_rHO.j3THhpUj10pZEkNGMW2gziyZ5ER BGXHSxWZ6qWQeuiiwmOKi0o4bgDpa8WeNVdUE4hdWjDDTmH87VpC7HnQA5l8- Received: by 76.13.27.55; Tue, 17 Mar 2015 23:01:42 +0000 Date: Tue, 17 Mar 2015 23:01:42 +0000 (UTC) From: Bill Mills To: John Bradley Message-ID: <717688957.203906.1426633302479.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_203905_937312737.1426633302436" Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 23:01:49 -0000 ------=_Part_203905_937312737.1426633302436 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable STS?=20 On Tuesday, March 17, 2015 2:40 PM, John Bradley w= rote: =20 This is fun:) I might ask what part of a OAuth 1.0a token is the user credential. =C2=A0 = That is a slippery idea in itself. =C2=A0The token is a reference to some n= otion of identity (in some cases) that needs to be dereferenced anyway. So in the same way a POP JWT access token in OAuth 2 that may indeed contai= n claims about the subject would need to be exchanged at a AS for a new tok= en containing claims about the subject and the new presenter, or depending = on the security model it could be included directly in a new self signed AT= . >From a enterprise policy point of view having a REST like STS functionality= is I think the right long term answer. John B. On Mar 17, 2015, at 6:32 PM, Bill Mills wrote: In practice one of the drawbacks of the Oauth 1.0a tokens was that they wer= e not proxyable and so a connection to the edge then means you have to unwr= ap that and make a new internal token to be usedwhich isn't as good as the = actual user credential.=C2=A0=20 On Tuesday, March 17, 2015 2:26 PM, John Bradley w= rote: =20 PoP tokens need to be presented with a proof the presenter knows the secre= t. =C2=A0That is the same principal as in OAuth 1.0a with needing to show k= nowledge of the "token secret". I don't know what you mean by proxies internally. =C2=A0 If the RS needs an= other token to access a resource it should use the assertion flow and authe= nticate itself to get another token based on the access token.Passing aroun= d a PoP token as a bearer token is insecure/bad. In OAuth 1.0a because of the tight relationship between the "Service Provid= er" and the "Protected Resource" people would be less likely to try it but = because the protected resource knows the "token secret" it could still do l= ots of unexpected bad things. Proxying access tokens is not something RS should do, they need to be excha= nged at a AS for a new AT with the correct rights and optionally binding it= to a new PoP key. John B. On Mar 17, 2015, at 6:14 PM, Bill Mills wrote: Yes. =C2=A0There's still the open question of whether/how PoP tokens can be= proxied internally within a site though. =C2=A0If they can be proxied then= it goes back to unsolved.=20 On Tuesday, March 17, 2015 2:12 PM, John Bradley w= rote: =20 Or by OAuth 2 PoP. =C2=A0 =C2=A0 On Mar 17, 2015, at 6:00 PM, Bill Mills wrote: "Yes but it is custom. =C2=A0People are inventing structured scopes like "a= ud:https://foo.com", and that potentially doesn't solve the security issue = if a client just passes on the scopes it receives in the error response, th= e bad RS just adds a scope for the good RS." This isn't solved by "aud", it is solved by OAuth 1.0a though.... =C2=A0 On Tuesday, March 17, 2015 1:54 PM, John Bradley w= rote: =20 Yes but it is custom. =C2=A0People are inventing structured scopes like "a= ud:https://foo.com", and that potentially doesn't solve the security issue = if a client just passes on the scopes it receives in the error response, th= e bad RS just adds a scope for the good RS. The client then potentially needs to understand the custom structures scope= s of every AS it might deal with. I think that would lead to lots of problems trying to make that a pattern l= ong term. =C2=A0 At teh moment yes you can do it with a scope as long as th= e client and AS both understand what is going on. We added "aud" as a separate parameter for PoP as the token format for diff= erent RS might be different as well as the symmetric =C2=A0pop keys needing= to be encrypted with different keys.Yes we could have invented a special s= cope to carry the audience but a separate parameter was much cleaner. I know some people have started using "aud" as a way to communicate the res= ource when a scope applies to multiple RS but they may take different token= formats JWT vs opaque etc. Brian commented that the "aud" parameter may be useful beyond PoP so we mig= ht want to think about documenting it in it's own mini spec, if I understoo= d him correctly. I think that may not be a bad idea as we are also planning on using it in N= APPS. John B. On Mar 17, 2015, at 5:39 PM, Bill Mills wrote: I don't think it's "overloading scope names" to use them that way. =C2=A0Th= e aud value(s) could as easily be carried in scope as anywhere. =C2=A0Nothi= ng says a scope can't be "https://foo.com", and that Foo.com requires that = scope to be present for a token to be accepted. =C2=A0I would not make it f= oo.com-read-mail for example. If it's more convenient to put it in aud I can accept that, but it's the sa= me functionality and can be implemented in scopes now.=20 On Tuesday, March 17, 2015 12:41 PM, John Bradley = wrote: =20 People have been overloading scope names to create implicit audience. =C2= =A0=C2=A0 The problem is that clients need to know via some magic method that you nee= d to ask for scope "purple" to get write access to RS 2. Having an explicit "aud" parameter gives clients a way to communicate to th= e AS what RS they are asking for a token for.=C2=A0 the security issue is that if a client discovers a API out via some out of = band mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y. =C2=A0 Unfortunately without POP tokens or at-least passing the URI of the RS to t= he AS via "aud", a bad RS could get a legitimate client to give it a token = that can be replayed at a legitimate RS. This was one of the issues that Eran Hammer-Lahav was particularly concerne= d about. =C2=A0 I think I proposed a "aud" parameter to the token endpoint back then as a a= lternative to requiring HMAC tokens, but that got lost in the confusion at = the time. At that time though people were not yet thinking about interoperable OAuth = API, =C2=A0only relatively tightly bound clients that were preconfigured fo= r the API endpoints they were using. In Health and other places we are starting to see standard clients that dis= cover API endpoints and configure themselves based on a users Identity to u= se a arbitrary OAuth AS, moving into federation of AT. That is one of the reasons POP will be important, as it prevents RS from mi= susing federated tokens by presenting them at other RS. The simplest thing to do is have the client say what RS it is trying to acc= ess explicitly (The "aud" parameter), and including an audience in the AT. = =C2=A0to protect against malicious RS. PoP is the step up that also protects against tokens being intercepted and = replayed by another client. John B. On Mar 17, 2015, at 4:10 PM, Bill Mills wrote: This may have been hashed out already and I missed it, but "aud" just becom= es another kind of scope, correct? =20 On Tuesday, March 17, 2015 8:50 AM, John Bradley w= rote: =20 You could do that, but it is probably safer for the AS to know what RS it = can issue tokens for and refuse to issue a token for RS A to a client askin= g for a token with RS X as the aud. John B. On Mar 16, 2015, at 8:27 PM, Dixie Baker wr= ote: The threat that RFC6819 4.6.4 describes is when a client obtains an AT and = then sends it to a counterfeit RS, which then uses the AT to access resourc= es from a legitimate RS, on the end-user's behalf. =C2=A0 The suggested countermeasure is a bit difficult to interpret: =C2=A0"Associ= ate the endpoint URL of the resource server the client talked to with the a= ccess token (e.g., in an audience field) and validate the association at a = legitimate resource server. =C2=A0The endpoint URL validation policy may be= strict (exact match) or more relaxed (e.g., same host). =C2=A0This would r= equire telling the authorization server about the resource server endpoint = URL in the authorization process." =C2=A0 As I read this, the suggestion is to have the client pass the URL of the ba= d RS in the request to the AS (using the audience field). =C2=A0The AS then= would include that RS URL in the AT. =C2=A0Then, when the client passes th= e AT to the bad RS, and it passes it on to the good RS, the good RS will ch= eck the audience field, compare that URL with its own, and refuse the reque= st. =C2=A0 -Dixie Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 11:39 AM, John Bradley wrote: Brian and I were talking about "aud" used as a parameter to the token endpo= int when using a code or refresh token to indicate what RS the resulting AT= will be used at. Sending a audience in the AT wouldn't help prevent the attack being discuss= ed, =C2=A0though it may stop other sorts of attacks if the RS can tell if a= AT was issued for it or another RS. In PoP having the AS check that you are sending the AT to the correct RS is= less important as the AT if stolen can't be used to replay against the rea= l AS. Though depending on the app the bogus RS feeding the app the wrong info may= well be a problem as well. John B. On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = wrote: I don't think putting an aud into an AT will help to prevent counterfeit RS= s (as long as the aud is nit directly derived from the original URL used by= the client to invoke the counterfeit RS. as long as the aud is a symbolic = name of any kind, the counterfeit RS will accept ATs for the legitimate RS = and just (ab)use it. POP on the contrary helps since the counterfeit RS, in order to send a mess= age to the legitimate RS, needs to produce a new digitally signed message u= sing the correct secret, which it doesn't know. kind regards,Torsten. Am 16.03.2015 um 17:40 schrieb Dixie Baker : Using the "aud" parameter makes sense to me. =C2=A0Good suggestion. Authenticating the client to the RS would not address the counterfeit RS th= reat.=C2=A0 -Dixie =C2=A0 Dixie B. Baker, Ph.D. Senior Partner Martin, Blanck and Associates Office (Redondo Beach, CA): =C2=A0310-791-9671 Mobile: =C2=A0310-279-2579 On Mar 16, 2015, at 6:43 AM, Brian Campbell wr= ote: We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identi= fy the RS to whom the AT should be issued. It is useful but it's mostly abo= ut getting format/content/etc of the AT correct for the RS rather than it i= s about preventing possible AT leaks. I do think an "aud(iance)" parameter at both token and authorization endpoi= nts would have utility beyond the POP work. So defining it independently mi= ght make sense.=20 On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: In POP key distribution we do introduce a "audiance" parameter to the token= _endpoint.=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distri= bution-01#section-3.1 It would be possible to have a small spec to define using "aud" with bearer= tokens, however that would be undefined behaviour at this point. I don't know of any clients that would try to access a RS server and then b= esed on the error response try and get a access token from the AS specified= in the error. In POP we are trying to both protect agains that attack and more common one= s like doing a MiM to intercept the AT or the RS being hacked and leaking t= he token. Using "aud" with bearer tokens would be useful, but probably won't stop the= majority of possible AT leaks. John B. On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = wrote: Hi Josh, =20 I'm not aware of a common practice to use such a parameter. The WG is inst= ead heading towards authenticated requests to the resource server (see http= s://tools.ietf.org/html/rfc6819#section-5.4.2).=20 =20 Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-ar= chitecture and further drafts on this topic. =20 kind regards, Torsten. =20 Am 03.03.2015 um 18:27 schrieb Josh Mandel: =20 Hi All,=20 In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource = Server"), RFC6819 describes a threat where a counterfeit resource server tr= icks a client into obtaining and sharing an access token from a legitimate = authorization server. One of the proposed mitigations involves: "telling th= e authorization server about the resource server endpoint URL in the author= ization process."=20 In other words, this mitigation would ask the client to pass an additiona= l parameter when redirecting to the Authorization server's "authorize" URL,= effectively something like:=20 https://auth-server/authorize? response_type=3Dcode& client_id=3D123& st= ate=3D456& scope=3Dread-all& redirect_uri=3Dhttps://app-server/after-auth& resourc= e_server_that_told_me_to_authorize_here=3Dhttps://attacker.com =20 (And if the authorization server saw a value it didn't like in the final = parameter, it would reject the request.)=20 This is obviously not appropriate in every authorization scenario, but it= is useful anytime there's a discovery process by which apps learn about au= thorization servers from resource servers. Since it's something of a common= need, I wanted to see if there was any common practice in how to name this= parameter, or whether it's worth registering a standard extension at=C2=A0= http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (= I don't see one there now -- possibly I'm just missing it.)=20 If so, what should it be called? The name I used in the example above is = a bit verbose :-)=20 Best,=20 =C2=A0 Josh =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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 ------=_Part_203905_937312737.1426633302436 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
STS?



On Tuesday, March 17, 2015 2:40= PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

=
This is = fun:)

I might ask what part of a OAuth 1.0a = token is the user credential.   That is a slippery idea in itself. &nb= sp;The token is a reference to some notion of identity (in some cases) that= needs to be dereferenced anyway.

So i= n the same way a POP JWT access token in OAuth 2 that may indeed contain cl= aims about the subject would need to be exchanged at a AS for a new token c= ontaining claims about the subject and the new presenter, or depending on t= he security model it could be included directly in a new self signed AT.

=
From a enterprise policy point of view h= aving a REST like STS functionality is I think the right long term answer.<= /div>

John B.



On Mar 17, 2015, = at 6:32 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
In practice one of the drawbacks of the Oaut= h 1.0a tokens was that they were not proxyable and so a connection to the e= dge then means you have to unwrap that and make a new internal token to be = usedwhich isn't as good as the actual user credential. 



<= div class=3D"yiv9016929184" dir=3D"ltr"> On Tuesday, March 17, 2015 2:26 PM, John Bradley <= ;v= e7jtb@ve7jtb.com> wrote:
=


PoP tokens need to be presented with a proof the presenter knows the secre= t.  That is the same principal as in OAuth 1.0a with needing to show k= nowledge of the "token secret".

I don't know= what you mean by proxies internally.   If the RS needs another token = to access a resource it should use the assertion flow and authenticate itse= lf to get another token based on the access token.
Passing around a PoP token as a bearer token is insecure/bad.

<= /div>
In OAuth 1.0a because of the tight relati= onship between the "Service Provider" and the "Protected Resource" people w= ould be less likely to try it but because the protected resource knows the = "token secret" it could still do lots of unexpected bad things.

Proxying access tokens is not something RS should= do, they need to be exchanged at a AS for a new AT with the correct rights= and optionally binding it to a new PoP key.

John B.



On Mar 17, 2015, at 6:14 PM, Bill Mills <wmil= ls_92105@yahoo.com> wrote:

Yes= .  There's still the open question of whether/how PoP tokens can be pr= oxied internally within a site though.  If they can be proxied then it= goes back to unsolved.



On Tuesd= ay, March 17, 2015 2:12 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:=


Or by OAuth 2 PoP.   &nbs= p;

<= /div>

On Mar 17, 2015, at 6:00 PM, Bill Mills <= wmills_92105@yahoo.com> wrote:

"Yes but it is custom.  People are inventing str= uctured scopes like "aud:https://foo.com"= , and that potentially doesn't solve the security issue if a client just pa= sses on the scopes it receives in the error response, the bad RS just adds = a scope for the good RS."

This isn't solved by "aud", it is solved by OAuth 1.0a though....=
 



On Tuesday, March 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com= > wrote:
=

Yes but it is c= ustom.  People are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't solve the = security issue if a client just passes on the scopes it receives in the err= or response, the bad RS just adds a scope for the good RS.

The client then potentially needs to understand the custom s= tructures scopes of every AS it might deal with.

I think that would lead to lots of problems trying to make that = a pattern long term.   At teh moment yes you can do it with a scope as= long as the client and AS both understand what is going on.


We added "aud" as a separate parameter for PoP as= the token format for different RS might be different as well as the symmet= ric  pop keys needing to be encrypted with different keys.
Yes we could have invented a special scope to carry = the audience but a separate parameter was much cleaner.

I know some people have started using "aud" as a way to = communicate the resource when a scope applies to multiple RS but they may t= ake different token formats JWT vs opaque etc.

Brian commented that the "aud" parameter may be useful beyond PoP = so we might want to think about documenting it in it's own mini spec, if I = understood him correctly.

I think that= may not be a bad idea as we are also planning on using it in NAPPS.
<= div class=3D"yiv9016929184">
John B.

On Mar 17, 2015, at 5:39 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

I don't think it's "overlo= ading scope names" to use them that way.  The aud value(s) could as ea= sily be carried in scope as anywhere.  Nothing says a scope can't be "= https://foo.com", and that Foo.com requires that scope to be present for a token to be = accepted.  I would not make it foo.com-= read-mail for example.

If it's more convenient to put it in aud I can accept that= , but it's the same functionality and can be implemented in scopes now.



On Tuesday, March 17, 2015 12:41 = PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


People have been overloading scope names to create imp= licit audience.   

The problem is = that clients need to know via some magic method that you need to ask for sc= ope "purple" to get write access to RS 2.

Ha= ving an explicit "aud" parameter gives clients a way to communicate to the = AS what RS they are asking for a token for. 

the security issue is th= at if a client discovers a API out via some out of band mechanism the OAuth= error code can tell the client go to AS X and ask for Scope Y.  

Unfortunately without POP tokens or at-lea= st passing the URI of the RS to the AS via "aud", a bad RS could get a legi= timate client to give it a token that can be replayed at a legitimate RS.

This was one of the issues that Eran Ha= mmer-Lahav was particularly concerned about.  

I think I proposed a "aud" parameter to the token endpoint ba= ck then as a alternative to requiring HMAC tokens, but that got lost in the= confusion at the time.

At that time t= hough people were not yet thinking about interoperable OAuth API,  onl= y relatively tightly bound clients that were preconfigured for the API endp= oints they were using.

In Health and o= ther places we are starting to see standard clients that discover API endpo= ints and configure themselves based on a users Identity to use a arbitrary = OAuth AS, moving into federation of AT.
<= br clear=3D"none" class=3D"yiv9016929184">
That is one of the reasons POP will be important, as it prevents RS from = misusing federated tokens by presenting them at other RS.

The simplest thing to do is have the client say what = RS it is trying to access explicitly (The "aud" parameter), and including a= n audience in the AT.  to protect against malicious RS.

PoP is the step up that also protects against tokens= being intercepted and replayed by another client.

John B.

On Mar 17, 2015, at 4:10 PM, Bill Mills <wmills_92= 105@yahoo.com> wrote:

This may have been hashed out already and I missed it, but = "aud" just becomes another kind of scope, correct?



=
On Tuesday, March 17, 20= 15 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
You could do that= , but it is probably safer for the AS to know what RS it can issue tokens f= or and refuse to issue a token for RS A to a client asking for a token with= RS X as the aud.

John B.
On Mar 16, 20= 15, at 8:27 PM, Dixie Baker <Dixie.Baker@martin-bl= anck.com> wrote:

The threat that RFC6819 4.6.4 describes is wh= en a client obtains an AT and then sends it to a counterfeit RS, which then= uses the AT to access resources from a legitimate RS, on the end-user's be= half.  

The suggested countermeasure is= a bit difficult to interpret:  "Associate the endpoint URL of the res= ource server the client talked to with the access token (e.g., in an audien= ce field) and validate the association at a legitimate resource server. &nb= sp;The endpoint URL validation policy may be strict (exact match) or more r= elaxed (e.g., same host).  This would require telling the authorizatio= n server about the resource server endpoint URL in the authorization proces= s."  

As I read this, the suggest= ion is to have the client pass the URL of the bad RS in the request to the = AS (using the audience field).  The AS then would include that RS URL = in the AT.  Then, when the client passes the AT to the bad RS, and it = passes it on to the good RS, the good RS will check the audience field, com= pare that URL with its own, and refuse the request.  

-Dixie



Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 11:39 AM, John Bradley <ve7j= tb@ve7jtb.com> wrote:

<= div class=3D"yiv9016929184" style=3D"word-wrap:break-word;">Brian and I wer= e talking about "aud" used as a parameter to the token endpoint when using = a code or refresh token to indicate what RS the resulting AT will be used a= t.

<= /div>
Sending a audience in the AT wouldn't hel= p prevent the attack being discussed,  though it may stop other sorts = of attacks if the RS can tell if a AT was issued for it or another RS.

In PoP having the AS check that you are se= nding the AT to the correct RS is less important as the AT if stolen can't = be used to replay against the real AS.
Though depending on the app the bogus RS feeding the app the wrong info ma= y well be a problem as well.

John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodd= erstedt <torsten@lodderstedt.net> wrote:

I don't= think putting an aud into an AT will help to prevent counterfeit RSs (as l= ong as the aud is nit directly derived from the original URL used by the cl= ient to invoke the counterfeit RS. as long as the aud is a symbolic name of= any kind, the counterfeit RS will accept ATs for the legitimate RS and jus= t (ab)use it.

POP on the contrary help= s since the counterfeit RS, in order to send a message to the legitimate RS= , needs to produce a new digitally signed message using the correct secret,= which it doesn't know.

kind regards,<= /div>
Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "au= d" parameter makes sense to me.  Good suggestion.

Authenticating the client to the RS would not address the counte= rfeit RS threat. 

-Dixie

=
 
Dixie B. Baker, Ph.D.
Senior= Partner
Martin, Blanck and Assoc= iates
Office (Redondo Beach, CA):=  310-791-9671
Mobile:  = ;310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv9016929184" ymailto=3D"mailto= :bcampbell@pingidentity.com" target=3D"_blank" href=3D"mailto:bcampbell@pin= gidentity.com">bcampbell@pingidentity.com> wrote:

We've used "aud" (optionally) with OAuth 2 and bea= rer tokens to help identify the RS to whom the AT should be issued. It is u= seful but it's mostly about getting format/content/etc of the AT correct fo= r the RS rather than it is about preventing possible AT leaks.

I do think an "aud(iance)" parameter at both token and authorization en= dpoints would have utility beyond the POP work. So defining it independentl= y might make sense.

On Sun, Mar 15, 2015 at 11:34 AM,= John Bradley <ve7jtb@ve7jtb.com= > wrote:
In POP key distribution we do introduce a "audiance" p= arameter to the token_endpoint. https://tools.ietf.or= g/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1

It would be possible to have a small spec to define u= sing "aud" with bearer tokens, however that would be undefined behaviour at= this point.

I don't know of any clien= ts that would try to access a RS server and then besed on the error respons= e try and get a access token from the AS specified in the error.

In POP we are trying to both protect agains that= attack and more common ones like doing a MiM to intercept the AT or the RS= being hacked and leaking the token.

U= sing "aud" with bearer tokens would be useful, but probably won't stop the = majority of possible AT leaks.

John B= .


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt &= lt;torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Toke= n Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation would = ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&
resource_= server_that_told_me_to_authorize_here=3Dht= tps://attacker.com

(And if the authorization server saw a= value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate in e= very authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-p= arameters/oauth-parameters.xhtml . (I don't see one there now -- possibly I'm just missing it.)

If so, what should it be called? The n= ame I used in the example above is a bit verbose :-)

Best,

  Josh


________________________________________=
_______
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org=
/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oau= th
<= br clear=3D"none" class=3D"yiv9016929184">

_________________________________________= ______
OAuth mailing list
OAuth@ie= tf.org
https://www.ietf.org= /mailman/listinfo/oauth







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth



<= /div>


=

<= /div>


=
<= /div>


<= /div>


<= /div>

------=_Part_203905_937312737.1426633302436-- From nobody Tue Mar 17 17:28:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A611A6FF2 for ; Tue, 17 Mar 2015 17:28:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 bB2ZGcapiJ-L for ; Tue, 17 Mar 2015 17:28:34 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (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 EDFCA1A1BB1 for ; Tue, 17 Mar 2015 17:28:33 -0700 (PDT) Received: by qgh62 with SMTP id 62so24433600qgh.1 for ; Tue, 17 Mar 2015 17:28:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WGvD46fWlt0gbEfwKO3g+VRvF39jhmhviaHoSGEVGXY=; b=cjG0Soyc92FMQb+yqQ0IESH4JkAtqAChA5eIBlvG8biWZFYYtue1PFNwky0t905giP CvqbgRDtd86tzATvrZ+1mz2rnS0wBQcPsPF3smPhFJUMfrwz7h29kWJPTUtVHd6/NYEz uFPXszmOOvkVLtnIegEewfQM7sxnUZM0VbL1RE2K1BYctV61y44LoI85Yy5imPIsE/WT 8S7F2HEb4hnlH6dMJaRoh7aT2wZcjHnd7S7YwNdAXRlK1Sh6bo4PzsiyB7gSAYmZ0QbJ 3tWZDLTRiBXHmtoBMNt7Oe1tGwRccfOmGpaVKQhZEOwbATHg/6XcLnOAZHFScC9TkZTl Ik9Q== X-Gm-Message-State: ALoCoQnGWOihXy8UOxoXK+SKEJ652Gw9LIvVTXN6DzLM9xN+37g/+J1dRGIqkk3VLjoP5//2t2x3 X-Received: by 10.55.51.77 with SMTP id z74mr67582075qkz.84.1426638513069; Tue, 17 Mar 2015 17:28:33 -0700 (PDT) Received: from [192.168.8.100] ([181.202.4.92]) by mx.google.com with ESMTPSA id n41sm10767787qkh.3.2015.03.17.17.28.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 17:28:32 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6681D2CC-4B58-485C-B6D6-696F89D30AD3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <717688957.203906.1426633302479.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Mar 2015 21:28:26 -0300 Message-Id: <61D3F8F8-2B44-4E0B-94EF-5CE3C3C89EE1@ve7jtb.com> References: <717688957.203906.1426633302479.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 00:28:41 -0000 --Apple-Mail=_6681D2CC-4B58-485C-B6D6-696F89D30AD3 Content-Type: multipart/alternative; boundary="Apple-Mail=_244FA191-761D-4423-A374-F471BF0F8687" --Apple-Mail=_244FA191-761D-4423-A374-F471BF0F8687 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Security Token Service (STS) Sorry it is WS-* speak = http://en.wikipedia.org/wiki/Security_token_service You can emulate some of it with the assertions extension.=20 The WG has a document as a starting position for a more general = approach. https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 Brian Campbell and I also documented our take on it for discussion. https://tools.ietf.org/html/draft-campbell-oauth-sts-01 At the moment they don't really take into account issuing PoP tokens in = exchange but I expect that would be added as a WG document progresses. It is on the WG to do list. John B. > On Mar 17, 2015, at 8:01 PM, Bill Mills = wrote: >=20 > STS? >=20 >=20 >=20 > On Tuesday, March 17, 2015 2:40 PM, John Bradley = wrote: >=20 >=20 > This is fun:) >=20 > I might ask what part of a OAuth 1.0a token is the user credential. = That is a slippery idea in itself. The token is a reference to some = notion of identity (in some cases) that needs to be dereferenced anyway. >=20 > So in the same way a POP JWT access token in OAuth 2 that may indeed = contain claims about the subject would need to be exchanged at a AS for = a new token containing claims about the subject and the new presenter, = or depending on the security model it could be included directly in a = new self signed AT. >=20 > =46rom a enterprise policy point of view having a REST like STS = functionality is I think the right long term answer. >=20 > John B. >=20 >=20 >=20 >> On Mar 17, 2015, at 6:32 PM, Bill Mills > wrote: >>=20 >> In practice one of the drawbacks of the Oauth 1.0a tokens was that = they were not proxyable and so a connection to the edge then means you = have to unwrap that and make a new internal token to be usedwhich isn't = as good as the actual user credential.=20 >>=20 >>=20 >>=20 >> On Tuesday, March 17, 2015 2:26 PM, John Bradley > wrote: >>=20 >>=20 >> PoP tokens need to be presented with a proof the presenter knows the = secret. That is the same principal as in OAuth 1.0a with needing to = show knowledge of the "token secret". >>=20 >> I don't know what you mean by proxies internally. If the RS needs = another token to access a resource it should use the assertion flow and = authenticate itself to get another token based on the access token. >> Passing around a PoP token as a bearer token is insecure/bad. >>=20 >> In OAuth 1.0a because of the tight relationship between the "Service = Provider" and the "Protected Resource" people would be less likely to = try it but because the protected resource knows the "token secret" it = could still do lots of unexpected bad things. >>=20 >> Proxying access tokens is not something RS should do, they need to be = exchanged at a AS for a new AT with the correct rights and optionally = binding it to a new PoP key. >>=20 >> John B. >>=20 >>=20 >>=20 >> On Mar 17, 2015, at 6:14 PM, Bill Mills > wrote: >>>=20 >>> Yes. There's still the open question of whether/how PoP tokens can = be proxied internally within a site though. If they can be proxied then = it goes back to unsolved. >>>=20 >>>=20 >>>=20 >>> On Tuesday, March 17, 2015 2:12 PM, John Bradley > wrote: >>>=20 >>>=20 >>> Or by OAuth 2 PoP. =20 >>>=20 >>>=20 >>>> On Mar 17, 2015, at 6:00 PM, Bill Mills > wrote: >>>>=20 >>>> "Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS." >>>>=20 >>>> This isn't solved by "aud", it is solved by OAuth 1.0a though.... >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>> On Tuesday, March 17, 2015 1:54 PM, John Bradley > wrote: >>>>=20 >>>>=20 >>>> Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS. >>>>=20 >>>> The client then potentially needs to understand the custom = structures scopes of every AS it might deal with. >>>>=20 >>>> I think that would lead to lots of problems trying to make that a = pattern long term. At teh moment yes you can do it with a scope as = long as the client and AS both understand what is going on. >>>>=20 >>>>=20 >>>> We added "aud" as a separate parameter for PoP as the token format = for different RS might be different as well as the symmetric pop keys = needing to be encrypted with different keys. >>>> Yes we could have invented a special scope to carry the audience = but a separate parameter was much cleaner. >>>>=20 >>>> I know some people have started using "aud" as a way to communicate = the resource when a scope applies to multiple RS but they may take = different token formats JWT vs opaque etc. >>>>=20 >>>> Brian commented that the "aud" parameter may be useful beyond PoP = so we might want to think about documenting it in it's own mini spec, if = I understood him correctly. >>>>=20 >>>> I think that may not be a bad idea as we are also planning on using = it in NAPPS. >>>>=20 >>>> John B. >>>>=20 >>>>> On Mar 17, 2015, at 5:39 PM, Bill Mills > wrote: >>>>>=20 >>>>> I don't think it's "overloading scope names" to use them that way. = The aud value(s) could as easily be carried in scope as anywhere. = Nothing says a scope can't be "https://foo.com ", and = that Foo.com requires that scope to be present for a = token to be accepted. I would not make it foo.com = -read-mail for example. >>>>>=20 >>>>> If it's more convenient to put it in aud I can accept that, but = it's the same functionality and can be implemented in scopes now. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tuesday, March 17, 2015 12:41 PM, John Bradley = > wrote: >>>>>=20 >>>>>=20 >>>>> People have been overloading scope names to create implicit = audience. =20 >>>>>=20 >>>>> The problem is that clients need to know via some magic method = that you need to ask for scope "purple" to get write access to RS 2. >>>>>=20 >>>>> Having an explicit "aud" parameter gives clients a way to = communicate to the AS what RS they are asking for a token for.=20 >>>>>=20 >>>>> the security issue is that if a client discovers a API out via = some out of band mechanism the OAuth error code can tell the client go = to AS X and ask for Scope Y. =20 >>>>>=20 >>>>> Unfortunately without POP tokens or at-least passing the URI of = the RS to the AS via "aud", a bad RS could get a legitimate client to = give it a token that can be replayed at a legitimate RS. >>>>>=20 >>>>> This was one of the issues that Eran Hammer-Lahav was particularly = concerned about. =20 >>>>>=20 >>>>> I think I proposed a "aud" parameter to the token endpoint back = then as a alternative to requiring HMAC tokens, but that got lost in the = confusion at the time. >>>>>=20 >>>>> At that time though people were not yet thinking about = interoperable OAuth API, only relatively tightly bound clients that = were preconfigured for the API endpoints they were using. >>>>>=20 >>>>> In Health and other places we are starting to see standard clients = that discover API endpoints and configure themselves based on a users = Identity to use a arbitrary OAuth AS, moving into federation of AT. >>>>>=20 >>>>> That is one of the reasons POP will be important, as it prevents = RS from misusing federated tokens by presenting them at other RS. >>>>>=20 >>>>> The simplest thing to do is have the client say what RS it is = trying to access explicitly (The "aud" parameter), and including an = audience in the AT. to protect against malicious RS. >>>>>=20 >>>>> PoP is the step up that also protects against tokens being = intercepted and replayed by another client. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>> On Mar 17, 2015, at 4:10 PM, Bill Mills > wrote: >>>>>>=20 >>>>>> This may have been hashed out already and I missed it, but "aud" = just becomes another kind of scope, correct? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tuesday, March 17, 2015 8:50 AM, John Bradley = > wrote: >>>>>>=20 >>>>>>=20 >>>>>> You could do that, but it is probably safer for the AS to know = what RS it can issue tokens for and refuse to issue a token for RS A to = a client asking for a token with RS X as the aud. >>>>>>=20 >>>>>> John B. >>>>>>> On Mar 16, 2015, at 8:27 PM, Dixie Baker = > = wrote: >>>>>>>=20 >>>>>>=20 >>>>>> The threat that RFC6819 4.6.4 describes is when a client obtains = an AT and then sends it to a counterfeit RS, which then uses the AT to = access resources from a legitimate RS, on the end-user's behalf. =20 >>>>>>=20 >>>>>> The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." =20 >>>>>>=20 >>>>>> As I read this, the suggestion is to have the client pass the URL = of the bad RS in the request to the AS (using the audience field). The = AS then would include that RS URL in the AT. Then, when the client = passes the AT to the bad RS, and it passes it on to the good RS, the = good RS will check the audience field, compare that URL with its own, = and refuse the request. =20 >>>>>>=20 >>>>>> -Dixie >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Dixie B. Baker, Ph.D. >>>>>> Senior Partner >>>>>> Martin, Blanck and Associates >>>>>> Office (Redondo Beach, CA): 310-791-9671 >>>>>> Mobile: 310-279-2579 >>>>>>=20 >>>>>> On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >>>>>>=20 >>>>>>=20 >>>>>> Brian and I were talking about "aud" used as a parameter to the = token endpoint when using a code or refresh token to indicate what RS = the resulting AT will be used at. >>>>>>=20 >>>>>> Sending a audience in the AT wouldn't help prevent the attack = being discussed, though it may stop other sorts of attacks if the RS = can tell if a AT was issued for it or another RS. >>>>>>=20 >>>>>> In PoP having the AS check that you are sending the AT to the = correct RS is less important as the AT if stolen can't be used to replay = against the real AS. >>>>>>=20 >>>>>> Though depending on the app the bogus RS feeding the app the = wrong info may well be a problem as well. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>>>>>>=20 >>>>>>=20 >>>>>> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>>>>>=20 >>>>>> POP on the contrary helps since the counterfeit RS, in order to = send a message to the legitimate RS, needs to produce a new digitally = signed message using the correct secret, which it doesn't know. >>>>>>=20 >>>>>> kind regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>>>>>=20 >>>>>>=20 >>>>>> Using the "aud" parameter makes sense to me. Good suggestion. >>>>>>=20 >>>>>> Authenticating the client to the RS would not address the = counterfeit RS threat.=20 >>>>>>=20 >>>>>> -Dixie >>>>>>=20 >>>>>> =20 >>>>>> Dixie B. Baker, Ph.D. >>>>>> Senior Partner >>>>>> Martin, Blanck and Associates >>>>>> Office (Redondo Beach, CA): 310-791-9671 >>>>>> Mobile: 310-279-2579 >>>>>>=20 >>>>>> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>>>>>=20 >>>>>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to = help identify the RS to whom the AT should be issued. It is useful but = it's mostly about getting format/content/etc of the AT correct for the = RS rather than it is about preventing possible AT leaks. >>>>>>>=20 >>>>>>> I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So = defining it independently might make sense.=20 >>>>>>>=20 >>>>>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley = > wrote: >>>>>>> In POP key distribution we do introduce a "audiance" parameter = to the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>>>>>=20 >>>>>>> It would be possible to have a small spec to define using "aud" = with bearer tokens, however that would be undefined behaviour at this = point. >>>>>>>=20 >>>>>>> I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the = AS specified in the error. >>>>>>>=20 >>>>>>> In POP we are trying to both protect agains that attack and more = common ones like doing a MiM to intercept the AT or the RS being hacked = and leaking the token. >>>>>>>=20 >>>>>>> Using "aud" with bearer tokens would be useful, but probably = won't stop the majority of possible AT leaks. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>>>>>=20 >>>>>>>> Hi Josh, >>>>>>>>=20 >>>>>>>> I'm not aware of a common practice to use such a parameter. The = WG is instead heading towards authenticated requests to the resource = server (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ).=20 >>>>>>>>=20 >>>>>>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>>>>>=20 >>>>>>>> kind regards, >>>>>>>> Torsten. >>>>>>>>=20 >>>>>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>>>>> Hi All, >>>>>>>>>=20 >>>>>>>>> In section 4.6.4 ("Threat: Access Token Phishing by = Counterfeit Resource Server"), RFC6819 describes a threat where a = counterfeit resource server tricks a client into obtaining and sharing = an access token from a legitimate authorization server. One of the = proposed mitigations involves: "telling the authorization server about = the resource server endpoint URL in the authorization process." >>>>>>>>>=20 >>>>>>>>> In other words, this mitigation would ask the client to pass = an additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>>>>>=20 >>>>>>>>> https://auth-server/authorize ? >>>>>>>>> response_type=3Dcode& >>>>>>>>> client_id=3D123& >>>>>>>>> state=3D456& >>>>>>>>> scope=3Dread-all& >>>>>>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>>>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>>>>>=20 >>>>>>>>> (And if the authorization server saw a value it didn't like in = the final parameter, it would reject the request.) >>>>>>>>>=20 >>>>>>>>> This is obviously not appropriate in every authorization = scenario, but it is useful anytime there's a discovery process by which = apps learn about authorization servers from resource servers. Since it's = something of a common need, I wanted to see if there was any common = practice in how to name this parameter, or whether it's worth = registering a standard extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>>>>>=20 >>>>>>>>> If so, what should it be called? The name I used in the = example above is a bit verbose :-) >>>>>>>>>=20 >>>>>>>>> Best, >>>>>>>>>=20 >>>>>>>>> Josh >>>>>>>>>=20 >>>>>>>>>=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 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_244FA191-761D-4423-A374-F471BF0F8687 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Security Token Service (STS)   Sorry it is WS-* = speak http://en.wikipedia.org/wiki/Security_token_service

You can emulate some of = it with the assertions extension. 

The WG has a document as a starting = position for a more general approach.
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01<= /a>


Brian Campbell and I also documented = our take on it for discussion.
https://tools.ietf.org/html/draft-campbell-oauth-sts-01

At the moment = they don't really take into account issuing PoP tokens in exchange but I = expect that would be added as a WG document progresses.

It is on the WG to do = list.

John = B.

On Mar 17, 2015, at 8:01 PM, Bill Mills = <wmills_92105@yahoo.com> wrote:

STS?



On Tuesday, = March 17, 2015 2:40 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


=
This is fun:)

I might ask = what part of a OAuth 1.0a token is the user credential.   That is a = slippery idea in itself.  The token is a reference to some notion = of identity (in some cases) that needs to be dereferenced = anyway.

So in the = same way a POP JWT access token in OAuth 2 that may indeed contain = claims about the subject would need to be exchanged at a AS for a new = token containing claims about the subject and the new presenter, or = depending on the security model it could be included directly in a new = self signed AT.

=46rom a = enterprise policy point of view having a REST like STS functionality is = I think the right long term answer.

John B.



On = Mar 17, 2015, at 6:32 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

In = practice one of the drawbacks of the Oauth 1.0a tokens was that they = were not proxyable and so a connection to the edge then means you have = to unwrap that and make a new internal token to be usedwhich isn't as = good as the actual user credential. 



On = Tuesday, March 17, 2015 2:26 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
PoP tokens need to be = presented with a proof the presenter knows the secret.  That is the = same principal as in OAuth 1.0a with needing to show knowledge of the = "token secret".

I don't know = what you mean by proxies internally.   If the RS needs another = token to access a resource it should use the assertion flow and = authenticate itself to get another token based on the access = token.
Passing around a PoP token as a = bearer token is insecure/bad.

In OAuth 1.0a because of the tight relationship = between the "Service Provider" and the "Protected Resource" people would = be less likely to try it but because the protected resource knows the = "token secret" it could still do lots of unexpected bad = things.

Proxying = access tokens is not something RS should do, they need to be exchanged = at a AS for a new AT with the correct rights and optionally binding it = to a new PoP key.

John B.



On Mar 17, 2015, at 6:14 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

Yes.  There's = still the open question of whether/how PoP tokens can be proxied = internally within a site though.  If they can be proxied then it = goes back to unsolved.



On = Tuesday, March 17, 2015 2:12 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
Or by OAuth 2 PoP. =    


On Mar 17, 2015, at 6:00 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

"Yes but it is custom. =  People are inventing structured scopes like "aud:https://foo.com", and that potentially = doesn't solve the security issue if a client just passes on the scopes = it receives in the error response, the bad RS just adds a scope for the = good RS."

This isn't solved by "aud", it is solved by = OAuth 1.0a though....
 


On = Tuesday, March 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
Yes but it is custom. =  People are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS.

The client = then potentially needs to understand the custom structures scopes of = every AS it might deal with.

I think that would lead to lots of problems = trying to make that a pattern long term.   At teh moment yes you = can do it with a scope as long as the client and AS both understand what = is going on.


We added "aud" as a separate parameter for PoP = as the token format for different RS might be different as well as the = symmetric  pop keys needing to be encrypted with different = keys.
Yes we could have invented a = special scope to carry the audience but a separate parameter was much = cleaner.

I know some = people have started using "aud" as a way to communicate the resource = when a scope applies to multiple RS but they may take different token = formats JWT vs opaque etc.

Brian commented that the "aud" parameter may be = useful beyond PoP so we might want to think about documenting it in it's = own mini spec, if I understood him correctly.

I think that = may not be a bad idea as we are also planning on using it in = NAPPS.

John = B.

On Mar 17, 2015, at 5:39 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

I don't think it's = "overloading scope names" to use them that way.  The aud value(s) = could as easily be carried in scope as anywhere.  Nothing says a = scope can't be "https://foo.com", and = that Foo.com requires that = scope to be present for a token to be accepted.  I would not make = it foo.com-read-mail for = example.

If it's more = convenient to put it in aud I can accept that, but it's the same = functionality and can be implemented in scopes now.



On = Tuesday, March 17, 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
People have been = overloading scope names to create implicit audience.   

The problem = is that clients need to know via some magic method that you need to ask = for scope "purple" to get write access to RS 2.

Having an = explicit "aud" parameter gives clients a way to communicate to the AS = what RS they are asking for a token for. 

the security = issue is that if a client discovers a API out via some out of band = mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y.  

Unfortunately = without POP tokens or at-least passing the URI of the RS to the AS via = "aud", a bad RS could get a legitimate client to give it a token that = can be replayed at a legitimate RS.

This was one of the issues that Eran = Hammer-Lahav was particularly concerned about.  

I think I = proposed a "aud" parameter to the token endpoint back then as a = alternative to requiring HMAC tokens, but that got lost in the confusion = at the time.

At that time = though people were not yet thinking about interoperable OAuth API, =  only relatively tightly bound clients that were preconfigured for = the API endpoints they were using.

In Health and other places we are starting to = see standard clients that discover API endpoints and configure = themselves based on a users Identity to use a arbitrary OAuth AS, moving = into federation of AT.

That is one of the reasons POP will be = important, as it prevents RS from misusing federated tokens by = presenting them at other RS.

The simplest thing to do is have the client say = what RS it is trying to access explicitly (The "aud" parameter), and = including an audience in the AT.  to protect against malicious = RS.

PoP is the = step up that also protects against tokens being intercepted and replayed = by another client.

John = B.

On Mar 17, 2015, at 4:10 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

This may have been hashed out already and I = missed it, but "aud" just becomes another kind of scope, = correct?




On = Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
You could do that, but it is probably safer for = the AS to know what RS it can issue tokens for and refuse to issue a = token for RS A to a client asking for a token with RS X as the = aud.

John B.
On Mar 16, 2015, at 8:27 PM, = Dixie Baker <Dixie.Baker@martin-blanck.co= m> wrote:

The threat that RFC6819 4.6.4 describes = is when a client obtains an AT and then sends it to a counterfeit RS, = which then uses the AT to access resources from a legitimate RS, on the = end-user's behalf.  

The suggested = countermeasure is a bit difficult to interpret:  "Associate the = endpoint URL of the resource server the client talked to with the access = token (e.g., in an audience field) and validate the association at a = legitimate resource server.  The endpoint URL validation policy may = be strict (exact match) or more relaxed (e.g., same host).  This = would require telling the authorization server about the resource server = endpoint URL in the authorization process."  

As I read = this, the suggestion is to have the client pass the URL of the bad RS in = the request to the AS (using the audience field).  The AS then = would include that RS URL in the AT.  Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request.  

-Dixie



Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 11:39 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Brian and I were talking about "aud" = used as a parameter to the token endpoint when using a code or refresh = token to indicate what RS the resulting AT will be used at.

Sending a = audience in the AT wouldn't help prevent the attack being discussed, =  though it may stop other sorts of attacks if the RS can tell if a = AT was issued for it or another RS.

In PoP having the AS check that you are sending = the AT to the correct RS is less important as the AT if stolen can't be = used to replay against the real AS.

Though depending on the app the bogus RS feeding = the app the wrong info may well be a problem as well.

John = B.

On = Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

I don't think putting an aud into an AT will = help to prevent counterfeit RSs (as long as the aud is nit directly = derived from the original URL used by the client to invoke the = counterfeit RS. as long as the aud is a symbolic name of any kind, the = counterfeit RS will accept ATs for the legitimate RS and just (ab)use = it.

POP on the = contrary helps since the counterfeit RS, in order to send a message to = the legitimate RS, needs to produce a new digitally signed message using = the correct secret, which it doesn't know.

kind = regards,
Torsten.



Am = 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.co= m>:

Using the "aud" parameter makes sense to me. =  Good suggestion.

Authenticating = the client to the RS would not address the counterfeit RS = threat. 

-Dixie

 
Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 6:43 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

We've used "aud" (optionally) = with OAuth 2 and bearer tokens to help identify the RS to whom the AT = should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I= do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:
In POP key = distribution we do introduce a "audiance" parameter to the = token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distr= ibution-01#section-3.1

It would be = possible to have a small spec to define using "aud" with bearer tokens, = however that would be undefined behaviour at this point.

I don't know = of any clients that would try to access a RS server and then besed on = the error response try and get a access token from the AS specified in = the error.

In POP we are = trying to both protect agains that attack and more common ones like = doing a MiM to intercept the AT or the RS being hacked and leaking the = token.

Using "aud" = with bearer tokens would be useful, but probably won't stop the majority = of possible AT leaks.

John = B.


On Mar 15, 2015, at 2:18 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.i= etf.org/html/rfc6819#section-5.4.2).

Please take a look onto http= ://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access = Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation = would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?<= /div>
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&= amp;
resource_server_that_told_me_to_authorize_here=3D<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv9016929184" = target=3D"_blank" = href=3D"https://attacker.com/">https://attacker.com

(And if the authorization server = saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate = in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.x= html . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? = The name I used in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


=



=



=



=



=



=

= --Apple-Mail=_244FA191-761D-4423-A374-F471BF0F8687-- --Apple-Mail=_6681D2CC-4B58-485C-B6D6-696F89D30AD3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMTgwMDI4MjdaMCMGCSqGSIb3DQEJBDEWBBRnJz9w1FBTwixmybsVHhVt OLVwojCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAzfy9MOC//QEiYsTGeOxAPSmnAo+QH676Ffnr/oNaYaAPKSJmnLDpJ WYX/IgPLdBbNP2WNQ1qKaSUvZ82GvtBJjVx0YzztrvzTobcTBW8syOFZUKE5nCBXSTW7JnFYZDt1 fVIo1WPQgW4jPusnWzCGri4fEEvNOX3Qx+2/xAExGiIkucVUdV2Yr4xrsZ1qlbBUylpC6txCHRkh ANvbvLRpNruMpQk/fQkcFqdcaMSDdavEwb9HTCPSK2Me9cHWQVggRVYJtw5sL2c5TsL4k5bWGxHV ULtB4eCtMznws5L+NDl1H4406bLyaGaQbXtWqMacb3QEzl3RMcomSucjx83eAAAAAAAA --Apple-Mail=_6681D2CC-4B58-485C-B6D6-696F89D30AD3-- From nobody Tue Mar 17 18:31:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1B51A8948 for ; Tue, 17 Mar 2015 18:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 D3VRf_PURWzC for ; Tue, 17 Mar 2015 18:31:29 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id EAE881A8946 for ; Tue, 17 Mar 2015 18:31:28 -0700 (PDT) X-AuditID: 12074422-f79d16d0000024cf-31-5508d56f115d 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id EC.22.09423.F65D8055; Tue, 17 Mar 2015 21:31:27 -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 t2I1VQvB030489; Tue, 17 Mar 2015 21:31:26 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2I1VNdr028535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Mar 2015 21:31:25 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9496AD1A-2099-4175-9FBB-EEE494DE44FB"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Justin Richer In-Reply-To: <61D3F8F8-2B44-4E0B-94EF-5CE3C3C89EE1@ve7jtb.com> Date: Tue, 17 Mar 2015 21:31:22 -0400 Message-Id: <09BD69DC-84D9-498B-BEEB-E82C77370DD1@mit.edu> References: <717688957.203906.1426633302479.JavaMail.yahoo@mail.yahoo.com> <61D3F8F8-2B44-4E0B-94EF-5CE3C3C89EE1@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphk+LIzCtJLcpLzFFi42IR4hTV1s2/yhFq8HyfmsX2V++YLbZu+8Bi cfLtKzaL1Xf/sll867rO7MDqsXPWXXaPJUt+MnlMO9LA7HH79kYWj1mzDjMFsEZx2aSk5mSW pRbp2yVwZVzdc5y14P8Gloonr1ewNTBef8bcxcjJISFgItF4dD87hC0mceHeerYuRi4OIYHF TBK3bz5nhnA2MkqsO/2BBcJ5yCTx6XEDUIaDQ1ggVGLv1FSQbl4BA4m5p74wgdjMApMYJW6u E4KYKiXx4PYaRhCbTUBVYvqaFiaQVk4BO4lrk21BwixA4Quz+sB2MQtsZ5R4sL6dGWKmlcSP U9+h9q5jlFi74RQLSEJEQEVi375HjCCDJATkJXo2pU9gFJyF5IxZSM6AsJMknk1cxgxha0ss W/gaytaU2N+9nAVTXEOi89tEVghbXmL72zlQcUuJxTNvQNXbStzqWwC1y07i0bRFrAsYuVcx yqbkVunmJmbmFKcm6xYnJ+blpRbpmurlZpbopaaUbmIERTC7i9IOxp8HlQ4xCnAwKvHw3ihg DxViTSwrrsw9xCjJwaQkyut+miNUiC8pP6UyI7E4I76oNCe1+BCjCtCuRxtWX2CUYsnLz0tV EuHVagGq401JrKxKLcqHKZPmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwXv5MlCjYFFq empFWmZOCUKaiYPzEKMEBw/QcO4rIMOLCxJzizPTIfKnGBWlxHlvgjQLgCQySvPgemGJ9xWj ONBbwrxTQdp5gEkbrvsV0GAmoMEt7Wwgg0sSEVJSDYz2tX7nw4N7RVqfqmzt4Qx0WuxaNH3v mYIpBWIfr+2Yq6XJnH5069nzTtHz3+XZe6zYsFx1Ibf4drktc1klHTZ0pCZtUTzanDDhyEXJ aLeZf3/xRviesYr5uDJSkyE3ju3iLYfVjXNSevZzbVB7tU/hx7c720MuCDaeOubVv2ty+wqT TZ9MvUqVWIozEg21mIuKEwFJ6mZElwMAAA== Archived-At: Cc: Dixie Baker , Matt Randall , "" Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 01:31:36 -0000 --Apple-Mail=_9496AD1A-2099-4175-9FBB-EEE494DE44FB Content-Type: multipart/alternative; boundary="Apple-Mail=_17CDAA2A-0C4C-4AD4-B0D0-CFFA521141A2" --Apple-Mail=_17CDAA2A-0C4C-4AD4-B0D0-CFFA521141A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I also drafted a more generalized mechanism (that was much less WS-*-y) = for doing an arbitrary token swap: https://tools.ietf.org/html/draft-richer-oauth-chain-00 = Phil had pretty much the same idea separately. Personally, I still think that the token-exchange draft needs to use a = syntactical mechanism like this instead of something so strictly tied to = the assertion formats. =E2=80=94 Justin > On Mar 17, 2015, at 8:28 PM, John Bradley wrote: >=20 > Security Token Service (STS) Sorry it is WS-* speak = http://en.wikipedia.org/wiki/Security_token_service = >=20 > You can emulate some of it with the assertions extension. >=20 > The WG has a document as a starting position for a more general = approach. > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 = >=20 >=20 > Brian Campbell and I also documented our take on it for discussion. > https://tools.ietf.org/html/draft-campbell-oauth-sts-01 = >=20 > At the moment they don't really take into account issuing PoP tokens = in exchange but I expect that would be added as a WG document = progresses. >=20 > It is on the WG to do list. >=20 > John B. >=20 >> On Mar 17, 2015, at 8:01 PM, Bill Mills > wrote: >>=20 >> STS? >>=20 >>=20 >>=20 >> On Tuesday, March 17, 2015 2:40 PM, John Bradley > wrote: >>=20 >>=20 >> This is fun:) >>=20 >> I might ask what part of a OAuth 1.0a token is the user credential. = That is a slippery idea in itself. The token is a reference to some = notion of identity (in some cases) that needs to be dereferenced anyway. >>=20 >> So in the same way a POP JWT access token in OAuth 2 that may indeed = contain claims about the subject would need to be exchanged at a AS for = a new token containing claims about the subject and the new presenter, = or depending on the security model it could be included directly in a = new self signed AT. >>=20 >> =46rom a enterprise policy point of view having a REST like STS = functionality is I think the right long term answer. >>=20 >> John B. >>=20 >>=20 >>=20 >>> On Mar 17, 2015, at 6:32 PM, Bill Mills > wrote: >>>=20 >>> In practice one of the drawbacks of the Oauth 1.0a tokens was that = they were not proxyable and so a connection to the edge then means you = have to unwrap that and make a new internal token to be usedwhich isn't = as good as the actual user credential. >>>=20 >>>=20 >>>=20 >>> On Tuesday, March 17, 2015 2:26 PM, John Bradley > wrote: >>>=20 >>>=20 >>> PoP tokens need to be presented with a proof the presenter knows the = secret. That is the same principal as in OAuth 1.0a with needing to = show knowledge of the "token secret". >>>=20 >>> I don't know what you mean by proxies internally. If the RS needs = another token to access a resource it should use the assertion flow and = authenticate itself to get another token based on the access token. >>> Passing around a PoP token as a bearer token is insecure/bad. >>>=20 >>> In OAuth 1.0a because of the tight relationship between the "Service = Provider" and the "Protected Resource" people would be less likely to = try it but because the protected resource knows the "token secret" it = could still do lots of unexpected bad things. >>>=20 >>> Proxying access tokens is not something RS should do, they need to = be exchanged at a AS for a new AT with the correct rights and optionally = binding it to a new PoP key. >>>=20 >>> John B. >>>=20 >>>=20 >>>=20 >>> On Mar 17, 2015, at 6:14 PM, Bill Mills > wrote: >>>>=20 >>>> Yes. There's still the open question of whether/how PoP tokens can = be proxied internally within a site though. If they can be proxied then = it goes back to unsolved. >>>>=20 >>>>=20 >>>>=20 >>>> On Tuesday, March 17, 2015 2:12 PM, John Bradley > wrote: >>>>=20 >>>>=20 >>>> Or by OAuth 2 PoP. >>>>=20 >>>>=20 >>>>> On Mar 17, 2015, at 6:00 PM, Bill Mills > wrote: >>>>>=20 >>>>> "Yes but it is custom. People are inventing structured scopes = like "aud:https://foo.com ", and that potentially = doesn't solve the security issue if a client just passes on the scopes = it receives in the error response, the bad RS just adds a scope for the = good RS." >>>>>=20 >>>>> This isn't solved by "aud", it is solved by OAuth 1.0a though.... >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tuesday, March 17, 2015 1:54 PM, John Bradley = > wrote: >>>>>=20 >>>>>=20 >>>>> Yes but it is custom. People are inventing structured scopes like = "aud:https://foo.com ", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS. >>>>>=20 >>>>> The client then potentially needs to understand the custom = structures scopes of every AS it might deal with. >>>>>=20 >>>>> I think that would lead to lots of problems trying to make that a = pattern long term. At teh moment yes you can do it with a scope as = long as the client and AS both understand what is going on. >>>>>=20 >>>>>=20 >>>>> We added "aud" as a separate parameter for PoP as the token format = for different RS might be different as well as the symmetric pop keys = needing to be encrypted with different keys. >>>>> Yes we could have invented a special scope to carry the audience = but a separate parameter was much cleaner. >>>>>=20 >>>>> I know some people have started using "aud" as a way to = communicate the resource when a scope applies to multiple RS but they = may take different token formats JWT vs opaque etc. >>>>>=20 >>>>> Brian commented that the "aud" parameter may be useful beyond PoP = so we might want to think about documenting it in it's own mini spec, if = I understood him correctly. >>>>>=20 >>>>> I think that may not be a bad idea as we are also planning on = using it in NAPPS. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>> On Mar 17, 2015, at 5:39 PM, Bill Mills > wrote: >>>>>>=20 >>>>>> I don't think it's "overloading scope names" to use them that = way. The aud value(s) could as easily be carried in scope as anywhere. = Nothing says a scope can't be "https://foo.com ", and = that Foo.com requires that scope to be present for a = token to be accepted. I would not make it foo.com = -read-mail for example. >>>>>>=20 >>>>>> If it's more convenient to put it in aud I can accept that, but = it's the same functionality and can be implemented in scopes now. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tuesday, March 17, 2015 12:41 PM, John Bradley = > wrote: >>>>>>=20 >>>>>>=20 >>>>>> People have been overloading scope names to create implicit = audience. >>>>>>=20 >>>>>> The problem is that clients need to know via some magic method = that you need to ask for scope "purple" to get write access to RS 2. >>>>>>=20 >>>>>> Having an explicit "aud" parameter gives clients a way to = communicate to the AS what RS they are asking for a token for. >>>>>>=20 >>>>>> the security issue is that if a client discovers a API out via = some out of band mechanism the OAuth error code can tell the client go = to AS X and ask for Scope Y. >>>>>>=20 >>>>>> Unfortunately without POP tokens or at-least passing the URI of = the RS to the AS via "aud", a bad RS could get a legitimate client to = give it a token that can be replayed at a legitimate RS. >>>>>>=20 >>>>>> This was one of the issues that Eran Hammer-Lahav was = particularly concerned about. >>>>>>=20 >>>>>> I think I proposed a "aud" parameter to the token endpoint back = then as a alternative to requiring HMAC tokens, but that got lost in the = confusion at the time. >>>>>>=20 >>>>>> At that time though people were not yet thinking about = interoperable OAuth API, only relatively tightly bound clients that = were preconfigured for the API endpoints they were using. >>>>>>=20 >>>>>> In Health and other places we are starting to see standard = clients that discover API endpoints and configure themselves based on a = users Identity to use a arbitrary OAuth AS, moving into federation of = AT. >>>>>>=20 >>>>>> That is one of the reasons POP will be important, as it prevents = RS from misusing federated tokens by presenting them at other RS. >>>>>>=20 >>>>>> The simplest thing to do is have the client say what RS it is = trying to access explicitly (The "aud" parameter), and including an = audience in the AT. to protect against malicious RS. >>>>>>=20 >>>>>> PoP is the step up that also protects against tokens being = intercepted and replayed by another client. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>> On Mar 17, 2015, at 4:10 PM, Bill Mills > wrote: >>>>>>>=20 >>>>>>> This may have been hashed out already and I missed it, but "aud" = just becomes another kind of scope, correct? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tuesday, March 17, 2015 8:50 AM, John Bradley = > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> You could do that, but it is probably safer for the AS to know = what RS it can issue tokens for and refuse to issue a token for RS A to = a client asking for a token with RS X as the aud. >>>>>>>=20 >>>>>>> John B. >>>>>>>> On Mar 16, 2015, at 8:27 PM, Dixie Baker = > = wrote: >>>>>>>>=20 >>>>>>>=20 >>>>>>> The threat that RFC6819 4.6.4 describes is when a client obtains = an AT and then sends it to a counterfeit RS, which then uses the AT to = access resources from a legitimate RS, on the end-user's behalf. >>>>>>>=20 >>>>>>> The suggested countermeasure is a bit difficult to interpret: = "Associate the endpoint URL of the resource server the client talked to = with the access token (e.g., in an audience field) and validate the = association at a legitimate resource server. The endpoint URL = validation policy may be strict (exact match) or more relaxed (e.g., = same host). This would require telling the authorization server about = the resource server endpoint URL in the authorization process." >>>>>>>=20 >>>>>>> As I read this, the suggestion is to have the client pass the = URL of the bad RS in the request to the AS (using the audience field). = The AS then would include that RS URL in the AT. Then, when the client = passes the AT to the bad RS, and it passes it on to the good RS, the = good RS will check the audience field, compare that URL with its own, = and refuse the request. >>>>>>>=20 >>>>>>> -Dixie >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Dixie B. Baker, Ph.D. >>>>>>> Senior Partner >>>>>>> Martin, Blanck and Associates >>>>>>> Office (Redondo Beach, CA): 310-791-9671 >>>>>>> Mobile: 310-279-2579 >>>>>>>=20 >>>>>>> On Mar 16, 2015, at 11:39 AM, John Bradley > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Brian and I were talking about "aud" used as a parameter to the = token endpoint when using a code or refresh token to indicate what RS = the resulting AT will be used at. >>>>>>>=20 >>>>>>> Sending a audience in the AT wouldn't help prevent the attack = being discussed, though it may stop other sorts of attacks if the RS = can tell if a AT was issued for it or another RS. >>>>>>>=20 >>>>>>> In PoP having the AS check that you are sending the AT to the = correct RS is less important as the AT if stolen can't be used to replay = against the real AS. >>>>>>>=20 >>>>>>> Though depending on the app the bogus RS feeding the app the = wrong info may well be a problem as well. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt = > wrote: >>>>>>>>=20 >>>>>>>=20 >>>>>>> I don't think putting an aud into an AT will help to prevent = counterfeit RSs (as long as the aud is nit directly derived from the = original URL used by the client to invoke the counterfeit RS. as long as = the aud is a symbolic name of any kind, the counterfeit RS will accept = ATs for the legitimate RS and just (ab)use it. >>>>>>>=20 >>>>>>> POP on the contrary helps since the counterfeit RS, in order to = send a message to the legitimate RS, needs to produce a new digitally = signed message using the correct secret, which it doesn't know. >>>>>>>=20 >>>>>>> kind regards, >>>>>>> Torsten. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Am 16.03.2015 um 17:40 schrieb Dixie Baker = >: >>>>>>>=20 >>>>>>>=20 >>>>>>> Using the "aud" parameter makes sense to me. Good suggestion. >>>>>>>=20 >>>>>>> Authenticating the client to the RS would not address the = counterfeit RS threat. >>>>>>>=20 >>>>>>> -Dixie >>>>>>>=20 >>>>>>>=20 >>>>>>> Dixie B. Baker, Ph.D. >>>>>>> Senior Partner >>>>>>> Martin, Blanck and Associates >>>>>>> Office (Redondo Beach, CA): 310-791-9671 >>>>>>> Mobile: 310-279-2579 >>>>>>>=20 >>>>>>> On Mar 16, 2015, at 6:43 AM, Brian Campbell = > wrote: >>>>>>>=20 >>>>>>>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to = help identify the RS to whom the AT should be issued. It is useful but = it's mostly about getting format/content/etc of the AT correct for the = RS rather than it is about preventing possible AT leaks. >>>>>>>>=20 >>>>>>>> I do think an "aud(iance)" parameter at both token and = authorization endpoints would have utility beyond the POP work. So = defining it independently might make sense. >>>>>>>>=20 >>>>>>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley = > wrote: >>>>>>>> In POP key distribution we do introduce a "audiance" parameter = to the token_endpoint. = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#secti= on-3.1 = >>>>>>>>=20 >>>>>>>> It would be possible to have a small spec to define using "aud" = with bearer tokens, however that would be undefined behaviour at this = point. >>>>>>>>=20 >>>>>>>> I don't know of any clients that would try to access a RS = server and then besed on the error response try and get a access token = from the AS specified in the error. >>>>>>>>=20 >>>>>>>> In POP we are trying to both protect agains that attack and = more common ones like doing a MiM to intercept the AT or the RS being = hacked and leaking the token. >>>>>>>>=20 >>>>>>>> Using "aud" with bearer tokens would be useful, but probably = won't stop the majority of possible AT leaks. >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt = > wrote: >>>>>>>>>=20 >>>>>>>>> Hi Josh, >>>>>>>>>=20 >>>>>>>>> I'm not aware of a common practice to use such a parameter. = The WG is instead heading towards authenticated requests to the resource = server (see https://tools.ietf.org/html/rfc6819#section-5.4.2 = ). >>>>>>>>>=20 >>>>>>>>> Please take a look onto = http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture = and = further drafts on this topic. >>>>>>>>>=20 >>>>>>>>> kind regards, >>>>>>>>> Torsten. >>>>>>>>>=20 >>>>>>>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel: >>>>>>>>>> Hi All, >>>>>>>>>>=20 >>>>>>>>>> In section 4.6.4 ("Threat: Access Token Phishing by = Counterfeit Resource Server"), RFC6819 describes a threat where a = counterfeit resource server tricks a client into obtaining and sharing = an access token from a legitimate authorization server. One of the = proposed mitigations involves: "telling the authorization server about = the resource server endpoint URL in the authorization process." >>>>>>>>>>=20 >>>>>>>>>> In other words, this mitigation would ask the client to pass = an additional parameter when redirecting to the Authorization server's = "authorize" URL, effectively something like: >>>>>>>>>>=20 >>>>>>>>>> https://auth-server/authorize = ? >>>>>>>>>> response_type=3Dcode& >>>>>>>>>> client_id=3D123& >>>>>>>>>> state=3D456& >>>>>>>>>> scope=3Dread-all& >>>>>>>>>> redirect_uri=3Dhttps://app-server/after-auth& = >>>>>>>>>> = resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com = >>>>>>>>>>=20 >>>>>>>>>> (And if the authorization server saw a value it didn't like = in the final parameter, it would reject the request.) >>>>>>>>>>=20 >>>>>>>>>> This is obviously not appropriate in every authorization = scenario, but it is useful anytime there's a discovery process by which = apps learn about authorization servers from resource servers. Since it's = something of a common need, I wanted to see if there was any common = practice in how to name this parameter, or whether it's worth = registering a standard extension at = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml = = . (I don't see one there now -- possibly I'm just missing it.) >>>>>>>>>>=20 >>>>>>>>>> If so, what should it be called? The name I used in the = example above is a bit verbose :-) >>>>>>>>>>=20 >>>>>>>>>> Best, >>>>>>>>>>=20 >>>>>>>>>> Josh >>>>>>>>>>=20 >>>>>>>>>>=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 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_17CDAA2A-0C4C-4AD4-B0D0-CFFA521141A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I also drafted a more generalized mechanism (that was much = less WS-*-y) for doing an arbitrary token swap:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

Phil had pretty = much the same idea separately. 

Personally, I still think that the = token-exchange draft needs to use a syntactical mechanism like this = instead of something so strictly tied to the assertion = formats.

 =E2=80=94 Justin

On = Mar 17, 2015, at 8:28 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Security Token = Service (STS)   Sorry it is WS-* speak http://en.wikipedia.org/wiki/Security_token_service

You can emulate some of = it with the assertions extension. 

The WG has a document as a starting = position for a more general approach.
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01<= /a>


Brian Campbell and I also documented = our take on it for discussion.
https://tools.ietf.org/html/draft-campbell-oauth-sts-01

At the moment = they don't really take into account issuing PoP tokens in exchange but I = expect that would be added as a WG document progresses.

It is on the WG to do = list.

John = B.

On Mar 17, 2015, at 8:01 PM, = Bill Mills <wmills_92105@yahoo.com> wrote:

STS?



On Tuesday, = March 17, 2015 2:40 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:


=
This is fun:)

I might ask = what part of a OAuth 1.0a token is the user credential.   That is a = slippery idea in itself.  The token is a reference to some notion = of identity (in some cases) that needs to be dereferenced = anyway.

So in the = same way a POP JWT access token in OAuth 2 that may indeed contain = claims about the subject would need to be exchanged at a AS for a new = token containing claims about the subject and the new presenter, or = depending on the security model it could be included directly in a new = self signed AT.

=46rom a = enterprise policy point of view having a REST like STS functionality is = I think the right long term answer.

John B.



On = Mar 17, 2015, at 6:32 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

In = practice one of the drawbacks of the Oauth 1.0a tokens was that they = were not proxyable and so a connection to the edge then means you have = to unwrap that and make a new internal token to be usedwhich isn't as = good as the actual user credential. 



On = Tuesday, March 17, 2015 2:26 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
PoP tokens need to be = presented with a proof the presenter knows the secret.  That is the = same principal as in OAuth 1.0a with needing to show knowledge of the = "token secret".

I don't know = what you mean by proxies internally.   If the RS needs another = token to access a resource it should use the assertion flow and = authenticate itself to get another token based on the access = token.
Passing around a PoP token as a = bearer token is insecure/bad.

In OAuth 1.0a because of the tight relationship = between the "Service Provider" and the "Protected Resource" people would = be less likely to try it but because the protected resource knows the = "token secret" it could still do lots of unexpected bad = things.

Proxying = access tokens is not something RS should do, they need to be exchanged = at a AS for a new AT with the correct rights and optionally binding it = to a new PoP key.

John B.



On Mar 17, 2015, at 6:14 PM, Bill Mills <wmills_92105@yahoo.com> = wrote:

Yes.  There's = still the open question of whether/how PoP tokens can be proxied = internally within a site though.  If they can be proxied then it = goes back to unsolved.



On = Tuesday, March 17, 2015 2:12 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
Or by OAuth 2 PoP. =    


On Mar 17, 2015, at 6:00 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

"Yes but it is custom. =  People are inventing structured scopes like "aud:https://foo.com", and that potentially = doesn't solve the security issue if a client just passes on the scopes = it receives in the error response, the bad RS just adds a scope for the = good RS."

This isn't solved by "aud", it is solved by = OAuth 1.0a though....
 


On = Tuesday, March 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
Yes but it is custom. =  People are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't = solve the security issue if a client just passes on the scopes it = receives in the error response, the bad RS just adds a scope for the = good RS.

The client = then potentially needs to understand the custom structures scopes of = every AS it might deal with.

I think that would lead to lots of problems = trying to make that a pattern long term.   At teh moment yes you = can do it with a scope as long as the client and AS both understand what = is going on.


We added "aud" as a separate parameter for PoP = as the token format for different RS might be different as well as the = symmetric  pop keys needing to be encrypted with different = keys.
Yes we could have invented a = special scope to carry the audience but a separate parameter was much = cleaner.

I know some = people have started using "aud" as a way to communicate the resource = when a scope applies to multiple RS but they may take different token = formats JWT vs opaque etc.

Brian commented that the "aud" parameter may be = useful beyond PoP so we might want to think about documenting it in it's = own mini spec, if I understood him correctly.

I think that = may not be a bad idea as we are also planning on using it in = NAPPS.

John = B.

On Mar 17, 2015, at 5:39 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

I don't think it's = "overloading scope names" to use them that way.  The aud value(s) = could as easily be carried in scope as anywhere.  Nothing says a = scope can't be "https://foo.com", and = that Foo.com requires that = scope to be present for a token to be accepted.  I would not make = it foo.com-read-mail for = example.

If it's more = convenient to put it in aud I can accept that, but it's the same = functionality and can be implemented in scopes now.



On = Tuesday, March 17, 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
People have been = overloading scope names to create implicit audience.   

The problem = is that clients need to know via some magic method that you need to ask = for scope "purple" to get write access to RS 2.

Having an = explicit "aud" parameter gives clients a way to communicate to the AS = what RS they are asking for a token for. 

the security = issue is that if a client discovers a API out via some out of band = mechanism the OAuth error code can tell the client go to AS X and ask = for Scope Y.  

Unfortunately = without POP tokens or at-least passing the URI of the RS to the AS via = "aud", a bad RS could get a legitimate client to give it a token that = can be replayed at a legitimate RS.

This was one of the issues that Eran = Hammer-Lahav was particularly concerned about.  

I think I = proposed a "aud" parameter to the token endpoint back then as a = alternative to requiring HMAC tokens, but that got lost in the confusion = at the time.

At that time = though people were not yet thinking about interoperable OAuth API, =  only relatively tightly bound clients that were preconfigured for = the API endpoints they were using.

In Health and other places we are starting to = see standard clients that discover API endpoints and configure = themselves based on a users Identity to use a arbitrary OAuth AS, moving = into federation of AT.

That is one of the reasons POP will be = important, as it prevents RS from misusing federated tokens by = presenting them at other RS.

The simplest thing to do is have the client say = what RS it is trying to access explicitly (The "aud" parameter), and = including an audience in the AT.  to protect against malicious = RS.

PoP is the = step up that also protects against tokens being intercepted and replayed = by another client.

John = B.

On Mar 17, 2015, at 4:10 PM, = Bill Mills <wmills_92105@yahoo.com> = wrote:

This may have been hashed out already and I = missed it, but "aud" just becomes another kind of scope, = correct?




On = Tuesday, March 17, 2015 8:50 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


=
You could do that, but it is probably safer for = the AS to know what RS it can issue tokens for and refuse to issue a = token for RS A to a client asking for a token with RS X as the = aud.

John B.
On Mar 16, 2015, at 8:27 PM, = Dixie Baker <Dixie.Baker@martin-blanck.co= m> wrote:

The threat that RFC6819 4.6.4 describes = is when a client obtains an AT and then sends it to a counterfeit RS, = which then uses the AT to access resources from a legitimate RS, on the = end-user's behalf.  

The suggested = countermeasure is a bit difficult to interpret:  "Associate the = endpoint URL of the resource server the client talked to with the access = token (e.g., in an audience field) and validate the association at a = legitimate resource server.  The endpoint URL validation policy may = be strict (exact match) or more relaxed (e.g., same host).  This = would require telling the authorization server about the resource server = endpoint URL in the authorization process."  

As I read = this, the suggestion is to have the client pass the URL of the bad RS in = the request to the AS (using the audience field).  The AS then = would include that RS URL in the AT.  Then, when the client passes = the AT to the bad RS, and it passes it on to the good RS, the good RS = will check the audience field, compare that URL with its own, and refuse = the request.  

-Dixie



Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 11:39 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Brian and I were talking about "aud" = used as a parameter to the token endpoint when using a code or refresh = token to indicate what RS the resulting AT will be used at.

Sending a = audience in the AT wouldn't help prevent the attack being discussed, =  though it may stop other sorts of attacks if the RS can tell if a = AT was issued for it or another RS.

In PoP having the AS check that you are sending = the AT to the correct RS is less important as the AT if stolen can't be = used to replay against the real AS.

Though depending on the app the bogus RS feeding = the app the wrong info may well be a problem as well.

John = B.

On = Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

I don't think putting an aud into an AT will = help to prevent counterfeit RSs (as long as the aud is nit directly = derived from the original URL used by the client to invoke the = counterfeit RS. as long as the aud is a symbolic name of any kind, the = counterfeit RS will accept ATs for the legitimate RS and just (ab)use = it.

POP on the = contrary helps since the counterfeit RS, in order to send a message to = the legitimate RS, needs to produce a new digitally signed message using = the correct secret, which it doesn't know.

kind = regards,
Torsten.



Am = 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.co= m>:

Using the "aud" parameter makes sense to me. =  Good suggestion.

Authenticating = the client to the RS would not address the counterfeit RS = threat. 

-Dixie

 
Dixie B. Baker, = Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): =  310-791-9671
Mobile: =  310-279-2579

On Mar 16, 2015, at = 6:43 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

We've used "aud" (optionally) = with OAuth 2 and bearer tokens to help identify the RS to whom the AT = should be issued. It is useful but it's mostly about getting = format/content/etc of the AT correct for the RS rather than it is about = preventing possible AT leaks.

I= do think an "aud(iance)" parameter at both token and authorization = endpoints would have utility beyond the POP work. So defining it = independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:
In POP key = distribution we do introduce a "audiance" parameter to the = token_endpoint. https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distr= ibution-01#section-3.1

It would be = possible to have a small spec to define using "aud" with bearer tokens, = however that would be undefined behaviour at this point.

I don't know = of any clients that would try to access a RS server and then besed on = the error response try and get a access token from the AS specified in = the error.

In POP we are = trying to both protect agains that attack and more common ones like = doing a MiM to intercept the AT or the RS being hacked and leaking the = token.

Using "aud" = with bearer tokens would be useful, but probably won't stop the majority = of possible AT leaks.

John = B.


On Mar 15, 2015, at 2:18 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.i= etf.org/html/rfc6819#section-5.4.2).

Please take a look onto http= ://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access = Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resource server endpoint URL in the authorization process."

In other words, this mitigation = would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively something like:

https://auth-server/authorize?<= /div>
response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
redirect_uri=3Dhttps://app-server/after-auth&= amp;
resource_server_that_told_me_to_authorize_here=3D<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv9016929184" = target=3D"_blank" = href=3D"https://attacker.com/">https://attacker.com

(And if the authorization server = saw a value it didn't like in the final parameter, it would reject the request.)

This is obviously not appropriate = in every authorization scenario, but it is useful anytime there's a discovery process by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.x= html . (I don't see one there now -- possibly I'm just missing = it.)

If so, what should it be called? = The name I used in the example above is a bit verbose :-)

Best,

  Josh


_______________________________________________
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







_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


=



=



=



=



=



=

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

= --Apple-Mail=_17CDAA2A-0C4C-4AD4-B0D0-CFFA521141A2-- --Apple-Mail=_9496AD1A-2099-4175-9FBB-EEE494DE44FB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJVCNVrAAoJEDPAngkbd+w9nBoH/AhmDmacR8WIhTyKHcQLbJDe 1Xbu5LIEr+nKiHxZM2DF2waUwarYd/MX0chWjnwGMuG7Rxh793IK5kEm6BLjHLhi 6cPawaP8gMjoAtdMYdjiKIPqumE6gC4ZMLsqmM5aMZTnySTaj/hcPJ+Dt3hY8Tf0 mfKG8B3fgBQ2dCtPrIC3VD/Jd8z+VYgqRocmlYXOCr+5cGbj4GaQiMicMJY6j4Jm f+RYukwKIpsWBAyAogL9kVZcBC8gVuyibpuvCkruYJFgjbe+TQZ+uw7Nj2so2mmD 9XqEej4+bkqfP1j2OpKLtwHFp7N7QidU49LRFRwXUrSYpYy9uYBsSw0d8a7lV24= =H8wr -----END PGP SIGNATURE----- --Apple-Mail=_9496AD1A-2099-4175-9FBB-EEE494DE44FB-- From nobody Sat Mar 21 09:10:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ACA1A036F for ; Sat, 21 Mar 2015 09:10:21 -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, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham 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 xqRnA1a-yTLT for ; Sat, 21 Mar 2015 09:10:19 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003: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 5EEDC1A0364 for ; Sat, 21 Mar 2015 09:10:19 -0700 (PDT) Received: by oifl3 with SMTP id l3so82642920oif.0 for ; Sat, 21 Mar 2015 09:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/axCo8ovfG10xeZoxvvmrqg9iKxpNzzTle1qfzWPwJM=; b=0aSDvBxIz9d1v9TRXgyT50XlYo5kWSAPT8HfvmP/eWXEkZAK8QqVLo90BmkcbXkw6M XFyvhDmm6cu9j1BKxKVX5tXEbIsimN9lJ3mk5FQcqH2831CYk6NpnA12iPOMrKVZ4nO2 lfU3m1DuvSWhvOXtIY5qfaQ5RLEjFYcoIhcR7rKVHAA207vhtK8V2+U1eGFrEB/O8Pme Duh7gqVh5++9KHF5s6G6mzjb8re2vswRP+xu69cm6FT3vpWi+xuedqVCbk2M4xvlLb8x eQ1LILLOftJF/G76jhNzB2+FAgvMGcmmf5SQHObkItz9RU3ap0y8znNsPZotyVXgACfJ bl8w== X-Received: by 10.182.213.102 with SMTP id nr6mr68146590obc.5.1426954218877; Sat, 21 Mar 2015 09:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.164.165 with HTTP; Sat, 21 Mar 2015 09:09:58 -0700 (PDT) In-Reply-To: <20150321071850.4682.qmail@mxw1903.dulles19-verio.com> References: <20150321071850.4682.qmail@mxw1903.dulles19-verio.com> From: Dick Hardt Date: Sat, 21 Mar 2015 09:09:58 -0700 Message-ID: To: legal@softalley.com, Oauth Wrap Wg Content-Type: multipart/alternative; boundary=001a11c3234c53bd1d0511ceab94 Archived-At: Cc: ip@softalley.com Subject: Re: [OAUTH-WG] Legal Notice on RFC 6749 - The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 16:10:21 -0000 --001a11c3234c53bd1d0511ceab94 Content-Type: text/plain; charset=UTF-8 I'm not the right person to respond to you. On Sat, Mar 21, 2015 at 12:18 AM, wrote: > > Dear. Mr. Hardt > Your committee for this RFC, and as a result, this RFC is infringing at > least one of our patents, namely, US8972590. > > I would like to further discuss this matter and see how we can settle this > issue before further legal escalation. > > For technical discussions you may contact IP@SoftAlley.com directly, with > a CC to myself. > > Regards, > Felipe Whitman > > Legal Council and Government Affairs > North America Group > SoftAlley, Inc. > > Please visit all our Corporate websites: > www.SoftAlley.com > www.InfoRender.com > www.KnowledgeSpace.co.uk > > ---------------- > This electronic message, including any and all attachments hereto, is > intended solely to be used by the individual or entity to which it is > addressed. If the reader of this message is not the intended recipient, or > an employee or agent responsible for delivering this message to its > intended recipient, you are herewith notified that any dissemination, > distribution, copying or retention of this communication or the information > contained herein is strictly prohibited. If you have received this message > communication in error, please notify us and immediately and permanently > delete the original and any copy or printout thereof. Although SoftAlley, > Inc., attempts to sweep e-mail and attachments for viruses, it does not > guarantee that either are virus-free and accepts no liability for any > damage sustained as a result of viruses. > --001a11c3234c53bd1d0511ceab94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not the right person to respond to you.

On Sat, Mar 21, 2015 at = 12:18 AM, <legal@softalley.com> wrote:

Dear. Mr. Hardt
Your committee for this RFC, and as a result, this RFC is infringing at lea= st one of our patents, namely, US8972590.

I would like to further discuss this matter and see how we can settle this = issue before further legal escalation.

For technical discussions you may contact IP@SoftAlley.com directly, with a= CC to myself.

Regards,
Felipe Whitman

Legal Council and Government Affairs
North America Group
SoftAlley, Inc.

Please visit all our Corporate websites:
www.SoftAlley.com
www.InfoRender.com<= /a>
www.Knowledge= Space.co.uk

----------------
This electronic message, including any and all attachments hereto, is inten= ded solely to be used by the individual or entity to which it is addressed.= If the reader of this message is not the intended recipient, or an employe= e or agent responsible for delivering this message to its intended recipien= t, you are herewith notified that any dissemination, distribution, copying = or retention of this communication or the information contained herein is s= trictly prohibited. If you have received this message communication in erro= r, please notify us and immediately and permanently delete the original and= any copy or printout thereof. Although SoftAlley, Inc., attempts to sweep = e-mail and attachments for viruses, it does not guarantee that either are v= irus-free and accepts no liability for any damage sustained as a result of = viruses.

--001a11c3234c53bd1d0511ceab94-- From nobody Sun Mar 22 13:48:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C301A1B1F for ; Sun, 22 Mar 2015 13:48:14 -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] autolearn=ham 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 jwi4RQxBNxsb for ; Sun, 22 Mar 2015 13:48:13 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20B71A0023 for ; Sun, 22 Mar 2015 13:48:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 12192E2038; Sun, 22 Mar 2015 16:48:11 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09989-02; Sun, 22 Mar 2015 16:48:10 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:2001:67c:370:176:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id B2F9BE2036; Sun, 22 Mar 2015 16:48:09 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2MKm8mQ025661; Sun, 22 Mar 2015 16:48:08 -0400 From: Derek Atkins To: oauth@ietf.org Date: Sun, 22 Mar 2015 16:48:08 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: oauth-chairs@tools.ietf.org Subject: [OAUTH-WG] Request for slides for WG meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 20:48:14 -0000 Hi, Can all speakers please send us your slides for the OAuth meeting. I'd prefer to receive them in PDF format. Please send them ASAP (and before lunch tomorrow). Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sun Mar 22 16:10:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35AF1A7008 for ; Sun, 22 Mar 2015 16:10:10 -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] autolearn=ham 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 h5L7vq81TObe for ; Sun, 22 Mar 2015 16:10:09 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C231A1B80 for ; Sun, 22 Mar 2015 16:10:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5D034E2039 for ; Sun, 22 Mar 2015 19:10:08 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10301-07 for ; Sun, 22 Mar 2015 19:10:07 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:2001:67c:370:176:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 8BA7EE2036 for ; Sun, 22 Mar 2015 19:10:06 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2MNA4Ed028757; Sun, 22 Mar 2015 19:10:04 -0400 From: Derek Atkins To: oauth@ietf.org Date: Sun, 22 Mar 2015 19:10:04 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [OAUTH-WG] Lunch (pre-)Meeting Monday X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 23:10:10 -0000 Hi, Hannes and I would like to have a lunch meeting before the OAUTH meeting to chat about various ongoing WG activities. If you're available and interested meet us at IETF Regstration at 11:30 and we'll find a place. I expect we'll leave by 11:35 so please be prompt. -derek and hannes -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sun Mar 22 18:15:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AB11A0469 for ; Sun, 22 Mar 2015 18:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 3kJfQgzAs_8b for ; Sun, 22 Mar 2015 18:15:00 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE471A0069 for ; Sun, 22 Mar 2015 18:15:00 -0700 (PDT) Received: from mail-ig0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKVQ9pE7llw+X0maUwBcmdY6rlt73VoebM@postini.com; Sun, 22 Mar 2015 18:15:00 PDT Received: by igcau2 with SMTP id au2so24102366igc.1 for ; Sun, 22 Mar 2015 18:14:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=o8oWI3xqL4eY8NAI3MJ8x0U8Te8IVoA5jZd0NbeJvv0=; b=FYWB4I0fpL4nqoPFFokKaAq9pT3cL1y18ruoQ6bcj6x0YEDxXb0dADfytcqegZ0ETY PRNEOeIRMZ+XoSd2eZK8zNZrTnlT/TbUFZbLKUVH5hObduznVsHmTTrfFVXsBcrCxQ4T vAs8Ar4zDxzJhPCN2hXTyLZJxLiwtFVmRB/7mkNkeUj3wdwGE3EtuaJPcaT43mAJ/XWc Mcpx/xWOqUglRZta7I2pJHq1LGJo/v6VSPEBFAGn3K8DXl0byw0L0Gvm82XzLJMXuTPm 3U8eCw40wxMeAbjmBnh1z75aeBWzLPoL5kBQA7jKm/C9TvPweDNcOpVljqXAcm/Afcou 75Xw== X-Gm-Message-State: ALoCoQmUGfztBY3+HO8lhYLoG5PfIFbb8MT4gPPjSCauZ/EhNrsEB3nwFRqBLAzuVvOR757D4pw5/4IWUkBb0BLcQorSCqhDLpruGB09fRcOk97eytcDNoXvrx2RYeDUp6VXpEKvrYzH X-Received: by 10.107.157.82 with SMTP id g79mr47411132ioe.72.1427073299435; Sun, 22 Mar 2015 18:14:59 -0700 (PDT) X-Received: by 10.107.157.82 with SMTP id g79mr47411122ioe.72.1427073299341; Sun, 22 Mar 2015 18:14:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Sun, 22 Mar 2015 18:14:29 -0700 (PDT) From: Brian Campbell Date: Sun, 22 Mar 2015 19:14:29 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a11408e5013806b0511ea65a8 Archived-At: Subject: [OAUTH-WG] AS in introduction of proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 01:15:02 -0000 --001a11408e5013806b0511ea65a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The introduction talks about an OAuth 2.0 authorization server as the JWT issuer, however, the term authorization server doesn=E2=80=99t appear anywhere else in the d= raft. Proof-of-possession semantics for JWT certainly can be applicable when an AS is the issuer but this draft has wider applicability than that. I might suggest that the introduction drop the authorization server talk in favor of something more general. Or clarify that an AS is just one potential issuer. As it is now, the intro reads overly specific. --001a11408e5013806b0511ea65a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The introduction talk= s about an OAuth 2.0 authorization server=C2=A0as the JWT issuer,=C2=A0howe= ver, the=C2=A0term=C2=A0authorization server doesn=E2=80=99t appear anywher= e else in the draft. Proof-of-possession=C2=A0semantics for JWT=C2=A0certai= nly=C2=A0can be=C2=A0applicable when an AS is the issuer=C2=A0but this draf= t has wider=C2=A0applicability than that. I might suggest that the introduc= tion drop the=C2=A0authorization server talk in favor of something more gen= eral. Or=C2=A0clarify that an AS is just one=C2=A0potential issuer. As it i= s now, the intro reads overly specific.
--001a11408e5013806b0511ea65a8-- From nobody Sun Mar 22 18:28:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6761A8738 for ; Sun, 22 Mar 2015 18:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 WUH4xszTVT8l for ; Sun, 22 Mar 2015 18:28:34 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8915A1A872F for ; Sun, 22 Mar 2015 18:28:34 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKVQ9sQhPUiBm3P5Dkl3eSZ9Z1Rqyty/Sy@postini.com; Sun, 22 Mar 2015 18:28:34 PDT Received: by igcqo1 with SMTP id qo1so27158385igc.0 for ; Sun, 22 Mar 2015 18:28:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=wA87SQzoYj3VlaDhbwwgzZKGGvjhTryUa0N7C4ZYu7U=; b=X02g4E067QwMYdcBxu86FmoVbM1Kn7Z/tY76tiPN1EXyc+hr5Zv/mze0iKlfDYb5O9 8Juo9DC8qXLLIkcZuNPXLli3e4eTP/pnMPxlftsMWszITfRez4QW8U94vXuCfDUr7jnK 7PklL8O/sq6XNKGQTuDIOk7DiUtbCnnNsFo2fw8El7cUR/Z5Y9pwF0Cw0Rti0/NShrRA en2He4IhQvHd7tu0fqgWa2/yViRPOWNN+bikhDoOObEY7pkgo1m7/Vx7MTwauShxLyQs DFy3g9ucbTHx8+eG7YF4ZUWSwQeePRxZF91CMgY57d5tpgf5+rwGijQAcZ9F7zIreBTJ iBHw== X-Gm-Message-State: ALoCoQnB7r8D0T9DgK7NZuPKfSn+GAKQa1FjdSI4xe6X/hmngptkKZMBwRiC4Nx9NXy6ue6tvKqwsgPfe+/YK8B/J3ZoH32tYObkiPVO5w1Fys2dN1j3M/uF9Rjy3SFrUygl3BAxCYfP X-Received: by 10.107.148.198 with SMTP id w189mr75414036iod.14.1427074113873; Sun, 22 Mar 2015 18:28:33 -0700 (PDT) X-Received: by 10.107.148.198 with SMTP id w189mr75414025iod.14.1427074113754; Sun, 22 Mar 2015 18:28:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Sun, 22 Mar 2015 18:28:03 -0700 (PDT) From: Brian Campbell Date: Sun, 22 Mar 2015 19:28:03 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a113ff6d89e75250511ea952e Archived-At: Subject: [OAUTH-WG] similar to a certificate? intro of proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 01:28:36 -0000 --001a113ff6d89e75250511ea952e Content-Type: text/plain; charset=UTF-8 It says, "The asymmetric key mechanism described above is conceptually similar to a certificate." near the end of https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-1 That kinda jumped out at me. I mean, I kinda see the point but it also seems like a pretty broad statement and potentially one that could be interpreted in unfavorable or unintended ways. Perhaps it should be left out? Otherwise maybe elaborate a bit on what is and what isn't similar to a certificate? --001a113ff6d89e75250511ea952e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It says, "The asymmetric key mechanism= described=C2=A0above is conceptually similar to a certificate." near = the end of https://tools.ietf.org/html/draft-ietf-oauth-proo= f-of-possession-02#section-1

That kinda jumped out at me. = I mean, I kinda see the point but it also seems like a pretty broad stateme= nt and potentially one that could be interpreted in unfavorable or unintend= ed ways.

Perhaps it should be left out? Otherwise maybe elabo= rate a bit on what is and what isn't similar to a certificate?
--001a113ff6d89e75250511ea952e-- From nobody Sun Mar 22 18:43:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FFD1A8745 for ; Sun, 22 Mar 2015 18:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 YwYrYQX7DpHe for ; Sun, 22 Mar 2015 18:43:21 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A971A8741 for ; Sun, 22 Mar 2015 18:43:20 -0700 (PDT) Received: from mail-ig0-f175.google.com ([209.85.213.175]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKVQ9vuMmUpWYqNCUr8/hY3PsJ1Q+4bhTF@postini.com; Sun, 22 Mar 2015 18:43:20 PDT Received: by ignm3 with SMTP id m3so24396168ign.0 for ; Sun, 22 Mar 2015 18:43:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=tDDpBT8d4BaMaF8NAvuu7IYYb0MYILZvdGJXCZullvU=; b=gloml5tKrrOhr27XdwRCXoM0WVmMyAtjsaELmx2Yt/Zrp2wVBNtPVg2ihOk/WWT1P4 tkY9QoAdqxiMSYT6Bu4Syw10+iVtvFY5gaQOZH/HZf/NL/hzD4PCLjestvLlOjkYy/8H by9MODYYGemeTZ1x1WWsvjSZawO9djs1MUWXNY0ZACjYDpizSKhbmbjSRnijJ9YLV360 9yrlhSm1Ao66nXtwWJTfpzhyU8qjjnIN0FPTqqP42m+L+lH1CimKCsh3OcaOSkhxoarA 1QALzNeB9mGJQ+M3zmvoX+yUY1ipoOgryhvA6c8rQiPx0ZKb4AHtbdlqc7ITFBjsCyyT TULA== X-Gm-Message-State: ALoCoQkiyO8GTv/zr6jR+KAUkRjh+o3cdC0kLhHWpV2yAP7uKgwxPeGhQ3lraCQkFcsiCH1po0hyMfW7D+YoTW9aSy8zXWRRkRFcw/zoZOSBcrHGYmOpLWH84+WQ66JExzvo/pEWms+B X-Received: by 10.107.35.70 with SMTP id j67mr109605390ioj.51.1427075000266; Sun, 22 Mar 2015 18:43:20 -0700 (PDT) X-Received: by 10.107.35.70 with SMTP id j67mr109605379ioj.51.1427075000147; Sun, 22 Mar 2015 18:43:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Sun, 22 Mar 2015 18:42:50 -0700 (PDT) From: Brian Campbell Date: Sun, 22 Mar 2015 19:42:50 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a1140dcf273bcbf0511eacae3 Archived-At: Subject: [OAUTH-WG] trouble reading the start of sec 3 proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 01:43:22 -0000 --001a1140dcf273bcbf0511eacae3 Content-Type: text/plain; charset=UTF-8 My brain hurt trying to parse the first sentence/paragraph from section 3 : "The presenter of a JWT declares that it possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter by including a "cnf" (confirmation) claim in the JWT whose value is a JSON object, with the JSON object containing a "jwk" (JSON Web Key) or "kid" (key ID) member identifying the key." The issuer includes the "cnf" claim and makes the declaration not the presenter. Sure, the presenter may be the issuer but that's a special case. Isn't it more accurate to say that it is the issuer who declares that the presenter can confirm itself by some cryptographic proof-of-possession of the key identified by the "cnf" claim? Or something more like that... --001a1140dcf273bcbf0511eacae3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My brain hurt trying to parse the first sentence= /paragraph from section 3: 
   "=
The presenter of a JWT declares that it possesses a particular key
   and that the recipient can cryptographically confirm proof-of-
   possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "jwk" (JSON Web Key) or "kid=
" (key ID)
   member identifying the key."
The issuer includes the= "cnf" claim and makes the declaration not the presenter. Sure, t= he presenter may be the issuer but that's a special case.

= Isn't it more accurate to say that it is the issuer who declares that t= he presenter can confirm itself by some cryptographic proof-of-possession o= f the key identified by the "cnf" claim? Or something more like t= hat...

--001a1140dcf273bcbf0511eacae3-- From nobody Sun Mar 22 18:54:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0801A875E for ; Sun, 22 Mar 2015 18:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 3GjoRqFHMb_q for ; Sun, 22 Mar 2015 18:54:31 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687331A8768 for ; Sun, 22 Mar 2015 18:54:31 -0700 (PDT) Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKVQ9yVtDDkwrCI3MNE3H+y1ejgmBTvaAg@postini.com; Sun, 22 Mar 2015 18:54:31 PDT Received: by igbqf9 with SMTP id qf9so27411378igb.1 for ; Sun, 22 Mar 2015 18:54:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=yLPhxsv7b32NLomyo3Ny8agKp9zzo8E93lxOICpO9NU=; b=I7aVvANnDfj4Furqy92xTKx/Jhle8h/fRHJDHEzYZ1dQ9Ge9Stlzun7Mqb+uzhddHK FZiAYm8725XvRB/C4SwV9czQYCCJdeNVadWkY0aketiCwD2b3DTetOTJJW5an9TJWYnS e9Scjj1JKgpwPk0ebMgKT0jtToaPnau6zmmHR7hcwqImWVLzT7JmmvPAds1BncQ3lJK4 B5/NHrCxW7nZkCIv6SwV2SDq0fc4jMBrzhqtvLr71RFTJib1f7/rPW/coYGCEtdyXppp 92pyFEZ4HCCyEsYQO2YxnMpd/9h58Dw+ERUZPRZlL9Dw3OM0zfLVq32e53WaajhFPwej cSIg== X-Gm-Message-State: ALoCoQn2dwGyHeZVCjQCeLGh5yysJWWV4JNNzBR3Pfm2xSxDZryhBbG2wMuuWGKL3FZBd4oy+wVCRfMjnh/vnClSdExi0WYbkNiuQc2rEjmzDYT3a92SjyE09fcj3tnOygWw2o5v/3dK X-Received: by 10.42.249.77 with SMTP id mj13mr3724533icb.80.1427075670568; Sun, 22 Mar 2015 18:54:30 -0700 (PDT) X-Received: by 10.42.249.77 with SMTP id mj13mr3724531icb.80.1427075670465; Sun, 22 Mar 2015 18:54:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Sun, 22 Mar 2015 18:54:00 -0700 (PDT) From: Brian Campbell Date: Sun, 22 Mar 2015 19:54:00 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=20cf3011e16967f3f70511eaf295 Archived-At: Subject: [OAUTH-WG] 2119 abuse at the end of section 3 proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 01:54:33 -0000 --20cf3011e16967f3f70511eaf295 Content-Type: text/plain; charset=UTF-8 At the end of section 3 it says, 'At least one of the "sub" and "iss" claims MUST be present in the JWT, and in some use cases, both MUST be present.' Admittedly I've misused RFC 2119 keywords a few times myself, so I say this aware of my own hypocrisy, but shouldn't the second "MUST" in that sentience be a little "must"? I don't think "some use cases" is enough to know when it applies. Maybe even spitting it up into two sentences? Something like, 'At least one of the "sub" and "iss" claims MUST be present in the JWT. Some use cases may require that both be present.' --20cf3011e16967f3f70511eaf295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the end of sectio= n 3 it says, 'At least one of the "sub" and "iss&quo= t; claims MUST be present in the JWT, and in some use cases, both MUST be p= resent.'

Admittedly I've misused RFC 2119 keywords a = few times myself, so I say this aware of my own hypocrisy, but shouldn'= t the second "MUST" in that sentience be a little "must"= ;? I don't think "some use cases" is enough to know when it a= pplies. Maybe even spitting it up into two sentences? Something like, '= At least one of the "sub" and "iss" claims MUST be pres= ent in the JWT. Some use cases may require that both be present.'


--20cf3011e16967f3f70511eaf295-- From nobody Sun Mar 22 19:14:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD351A1A59 for ; Sun, 22 Mar 2015 19:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Oi89ge4ImrcU for ; Sun, 22 Mar 2015 19:14:11 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B43A1A8772 for ; Sun, 22 Mar 2015 19:14:11 -0700 (PDT) Received: from mail-ig0-f182.google.com ([209.85.213.182]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKVQ928tMIrAAjZbFCNVWouCVMXacVw0R3@postini.com; Sun, 22 Mar 2015 19:14:11 PDT Received: by igcau2 with SMTP id au2so24690311igc.1 for ; Sun, 22 Mar 2015 19:14:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=WGzZ+cuuELNoBy+lUhO0ockWZMoVcr89KX2vNAhcNTw=; b=DCjEVM+QrFxJ1NVefMJ26qeklHw5JOYzt6KR+kypUgl9kCzIX5aHhlBPjUqVuv2FKp Jg1K2wSA/LwcyaxmvHboQT3GeVTScEUCjCFoyOrrZm90om0jOA8WWgCvX7SLl8EpINIy NUhQzPwi+149AiDhHJOK2DMwj0VoFjMLBZPYGnbrf/YCzFyO32845F0vL9Uayr9XSPPa H8czGnNCk68QSqDJToCu3r6MNA33SZIrEiIpNsrXGxklBGReFWAyI6L5BpHDAzzPKEnS hDWdVxIkf48PbqlJ7BrYF8Lahp64po0D+MN0kJ4Gbv/mdOYlZprQkbGvUlK1EPi98Wb/ j+XQ== X-Gm-Message-State: ALoCoQlrzQ3/bhIMGlJyO4YUG0TCI2cD1ROX9qQBJ9YfvmKlvTdUiYskcK95wMYqz8y8OaZcHNU8vsbX5KYio2UkYeQnjny0t8WiJ+IQaSo1thThPrxbpezzuVA4S/P840G5ASt+j4jR X-Received: by 10.42.249.77 with SMTP id mj13mr3779918icb.80.1427076850535; Sun, 22 Mar 2015 19:14:10 -0700 (PDT) X-Received: by 10.42.249.77 with SMTP id mj13mr3779912icb.80.1427076850383; Sun, 22 Mar 2015 19:14:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Sun, 22 Mar 2015 19:13:39 -0700 (PDT) From: Brian Campbell Date: Sun, 22 Mar 2015 20:13:39 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=20cf3011e169bc0f7f0511eb38f6 Archived-At: Subject: [OAUTH-WG] refs and links in proof-of-possession-02 section 3.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 02:14:12 -0000 --20cf3011e169bc0f7f0511eb38f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In =C2=A73.2. Proof-of-Possession of a Symmetric Key it has "The rules for encrypting a JWK are found in Section 6 of the JSON Web Key [JWK] specification.", which has two issues. 1) the Section 6 link is to the same document at https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section= -6 which kinda works because it's the References. But is probably not what was intended. I think http://www.ietf.org/mail-archive/web/jose/current/msg04571.html has some info on how to fix that kind of thing. 2) It should actually refer to section 7 of JWK rather than 6 as section 6 is about "String Comparison Rules" and 7 is "Encrypted JWK and Encrypted JWK Set Formats". --20cf3011e169bc0f7f0511eb38f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In =C2=A73.2. Proof-of-Possession of= a Symmetric Key it has "The rules for encrypting a JWK are found = in Section 6 of the JSON Web Key [JWK] specification.", which has two = issues.

1) the Section 6 link is to the s= ame document at https://tools.ietf.org/html/draft-ietf-oauth= -proof-of-possession-02#section-6 which kinda works because it's th= e References. But is probably not what was intended. I think http://www.ie= tf.org/mail-archive/web/jose/current/msg04571.html has some info on how= to fix that kind of thing.

2) It should actually refer t= o section 7 of JWK rather than 6 as section 6 is about "Str= ing Comparison Rules" and 7 is "Encrypted JWK and Encrypted JWK S= et Formats".
--20cf3011e169bc0f7f0511eb38f6-- From nobody Sun Mar 22 21:12:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2421A87C7 for ; Sun, 22 Mar 2015 21:12:27 -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, SPF_PASS=-0.001] autolearn=ham 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 3evLSA4DHkcK for ; Sun, 22 Mar 2015 21:12:25 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003: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 8B7B61A87CD for ; Sun, 22 Mar 2015 21:12:25 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so114658783obb.1 for ; Sun, 22 Mar 2015 21:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MSjfaTH70SWDUH5zshVg/r4ONe6MaOlTlAshHNGz+O0=; b=xHEPZqyU3JqYRB15EdeXHVE+kzvfwTdrWYCkfFnyDt4Ccem+4wQGt6QwKwZ9hk0xDN 6xirJDkOblVevYPli4acHIuX0WD2IY2xEo5+s1KBPfqN1ku4+gLgNd9ce2s8fYIREMdo Bs1PDqyVYfKx5Z7n0c6N+l+boZcBa1pF376JbRwb8t2T2ZAF1FZRU8ficW40X5mmW8uH MpmHR4KMK/ZjWZ8+rh94v8ZUF9VbTkFJSq4VQwFPHh+N1cL1kDgzygEOekxKzaYz2Ydj bE/gxGSC8ONcCGuaLP4/fJBUTJyb9dStG1SbejPXRiiJW+RJzTfQhJ29QZKo2dq/2/vz /jrg== MIME-Version: 1.0 X-Received: by 10.202.180.87 with SMTP id d84mr56615152oif.0.1427083945057; Sun, 22 Mar 2015 21:12:25 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Sun, 22 Mar 2015 21:12:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 13:12:25 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113cc7e09c235a0511ecdf42 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] 2119 abuse at the end of section 3 proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 04:12:27 -0000 --001a113cc7e09c235a0511ecdf42 Content-Type: text/plain; charset=UTF-8 +1 2015-03-23 10:54 GMT+09:00 Brian Campbell : > At the end of section 3 > > it says, 'At least one of the "sub" and "iss" claims MUST be present in the > JWT, and in some use cases, both MUST be present.' > > Admittedly I've misused RFC 2119 keywords a few times myself, so I say > this aware of my own hypocrisy, but shouldn't the second "MUST" in that > sentience be a little "must"? I don't think "some use cases" is enough to > know when it applies. Maybe even spitting it up into two sentences? > Something like, 'At least one of the "sub" and "iss" claims MUST be present > in the JWT. Some use cases may require that both be present.' > > > > _______________________________________________ > 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 --001a113cc7e09c235a0511ecdf42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

2015-03-23 10:54 GMT+09:00 Brian Campbell <bcampbell@ping= identity.com>:
At the end of section 3 it s= ays, 'At least one of the "sub" and "iss" claims MU= ST be present in the JWT, and in some use cases, both MUST be present.'=

Admittedly I've misused RFC 2119 keywords a few times my= self, so I say this aware of my own hypocrisy, but shouldn't the second= "MUST" in that sentience be a little "must"? I don'= ;t think "some use cases" is enough to know when it applies. Mayb= e even spitting it up into two sentences? Something like, 'At least one= of the "sub" and "iss" claims MUST be present in the J= WT. Some use cases may require that both be present.'

=

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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--001a113cc7e09c235a0511ecdf42-- From nobody Sun Mar 22 22:05:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50681A8824; Sun, 22 Mar 2015 22:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 0cnozMw9a1qI; Sun, 22 Mar 2015 22:05:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25C1A8830; Sun, 22 Mar 2015 22:05:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323050541.5381.26951.idtracker@ietfa.amsl.com> Date: Sun, 22 Mar 2015 22:05:41 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-25.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:05:45 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-25.txt Pages : 40 Date : 2015-03-22 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-25 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-25 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 Sun Mar 22 22:07:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3546A1A882F; Sun, 22 Mar 2015 22:07:11 -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] autolearn=ham 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 0KFIz7KYBmBA; Sun, 22 Mar 2015 22:07:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 514931A8830; Sun, 22 Mar 2015 22:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323050706.16187.96617.idtracker@ietfa.amsl.com> Date: Sun, 22 Mar 2015 22:07:06 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:07:11 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-10.txt Pages : 18 Date : 2015-03-22 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-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 Sun Mar 22 22:11:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794C1A8823; Sun, 22 Mar 2015 22:11:05 -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] autolearn=ham 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 mgimHnkylfeW; Sun, 22 Mar 2015 22:11:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FEE1A883E; Sun, 22 Mar 2015 22:11:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323051103.14518.94469.idtracker@ietfa.amsl.com> Date: Sun, 22 Mar 2015 22:11:03 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:11:06 -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 Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-06.txt Pages : 14 Date : 2015-03-22 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-introspection-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 22 22:26:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152B71A8845; Sun, 22 Mar 2015 22:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tWEOWGRGAixM; Sun, 22 Mar 2015 22:26:26 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64941A8847; Sun, 22 Mar 2015 22:26:25 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-77-550fa3ffed96 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (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 C4.C1.03355.FF3AF055; Mon, 23 Mar 2015 01:26:23 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2N5QNfA014303; Mon, 23 Mar 2015 01:26:23 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2N5QLC3030333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Mar 2015 01:26:22 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2N5QK9g004187; Mon, 23 Mar 2015 01:26:20 -0400 (EDT) Date: Mon, 23 Mar 2015 01:26:20 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUixCmqrPt/MX+owfweE4ujm1exWJx8+4rN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ71+tYC9YI1gxf8Np5gbG6XxdjJwcEgImEpNbtrBA 2GISF+6tZ+ti5OIQEljMJLFgewMLhLORUeL71LnsEM4hJonni/9DlTUwSjy784ANpJ9FQFvi 0rK1jCA2m4CKxMw3G8HiIgLCEru3vmPuYuTgYBYQkmh7Hg0SFhawl/jb+gAszCvgKNHxPw4k LCqgI7F6/xSwi3gFBCVOznwCZjMLaEksn76NZQIj/ywkqVlIUgsYmVYxyqbkVunmJmbmFKcm 6xYnJ+blpRbpGuvlZpbopaaUbmIEh5sk3w7GrweVDjEKcDAq8fBWBPCHCrEmlhVX5h5ilORg UhLltVgAFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCyz4PKMebklhZlVqUD5OS5mBREufd9IMv REggPbEkNTs1tSC1CCYrw8GhJMEbD4wrIcGi1PTUirTMnBKENBMHJ8hwHqDhjCA1vMUFibnF mekQ+VOMilLivOIgCQGQREZpHlwvLB28YhQHekWY99YioCoeYCqB634FNJgJaPC5fD6QwSWJ CCmpBsYywRv7o7xbJ1vIpCzbJcjxKkplkk6aePfjFxtVTL9N0y6KvCV4Vub6iq3pQo4BRblz jz7rtUq9cra9w27LztTf/vI3r1h9OiH0ofrBPyORWK3mDj++t8faF2csiwmqdTLW14uWUAya m73j5sE1P65/nyow0+bsizvTLz9OujBnzaYvumZHjtopsRRnJBpqMRcVJwIApR3RDOICAAA= Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:26:28 -0000 Hi all, During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed an old comment from Matt back in December 2013, in http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html . The relevant point here is that sending a scope of "" (the empty string) during the authorization request violates the ABNF in RFC 6749. (The other concerns seem to have been addressed by suggesting that a single scope be used, when recommending against a space-separated list.) In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Server Response to Failed Authentication"), we provide a way for the server to tell the client what scope to use, in a custom JSON message defined in the sasl-oauth document. This error response has no obligation to comply to the ABNF of RFC 6749, so saying both that the scope field is optional and that it "may be empty which implies that unscoped tokens are required, or a scope value" does not cause any compliance issues. However, a few paragraphs down, we furthermore say that "[i]f the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is required to access the resource." The phrase "empty scope" here is concerning, and seems to suggest sending scope="", which is disallowed by RFC 6749. The simple fix would be to just replace "empty scope (unscoped token)" with "unscoped token". However, it is a bit aesthetically unpleasing to have our new JSON structure diverge from the existing ABNF guidelines; we may wish to just utilize the optionality of the scope field in the server's response to failed authentication, and remove the mention of an empty value for that field. This proposal is a change to the wire protocol, and so we would need consensus from the working group to move forward with it -- in particular, we would like to know if there are existing implementations which would be affected by this change. Please comment about the proposal to remove the option of an empty scope in the server's response to failed authentication, both from the protocol change standpoint and from its effects on existing implementations. Thank you, Ben From nobody Sun Mar 22 22:44:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D441A8866 for ; Sun, 22 Mar 2015 22:44: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, SPF_PASS=-0.001] autolearn=ham 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 JCZQbQtsoO5c for ; Sun, 22 Mar 2015 22:44:13 -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 5793B1A885E for ; Sun, 22 Mar 2015 22:44:13 -0700 (PDT) Received: by oifl3 with SMTP id l3so102385781oif.0 for ; Sun, 22 Mar 2015 22:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PTbnGqKCjmF5xLuHlUyE3wpW5EP+yYOUZ0TBR/7ttL4=; b=ydTj6w/tHH8xD2nY1LA28QoKEMEYCCcQhafPJiqhlNx6LvLgikrVHoJhonVOpCyt8a LOkA/+3aJQfr2fwHp7ROHlQYfx8zVgJBU2cIYpsHkjU2WF6Qh9usr31xLh+S5rZ/ZFZR +c7Wm+QhwNsuBqytrCCGNhlAo1gVE5ouf2AD/7cyzCuUzd2COk0d7vzV216Eiq209rqo azSHMhEQBE8LhT6GjwBJlOSYiFTXwGWkInvlzAr+OJ34k3gLpF0pYFvxbFysJ+iFY5Zq 8sUh2fj2Tuxn34auYWVYpDftfCnTLABEPNhOCgIdKTGQg8ICEBiWpbbBS3vfYCsBSI7V 0M0w== MIME-Version: 1.0 X-Received: by 10.182.24.133 with SMTP id u5mr73726767obf.27.1427089452801; Sun, 22 Mar 2015 22:44:12 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Sun, 22 Mar 2015 22:44:12 -0700 (PDT) In-Reply-To: <09BD69DC-84D9-498B-BEEB-E82C77370DD1@mit.edu> References: <717688957.203906.1426633302479.JavaMail.yahoo@mail.yahoo.com> <61D3F8F8-2B44-4E0B-94EF-5CE3C3C89EE1@ve7jtb.com> <09BD69DC-84D9-498B-BEEB-E82C77370DD1@mit.edu> Date: Mon, 23 Mar 2015 14:44:12 +0900 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c30864e5a7430511ee2751 Archived-At: Cc: "" , Matt Randall , Dixie Baker Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:44:19 -0000 --001a11c30864e5a7430511ee2751 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry to come in so late, and I admit that I have just skimmed the thread, but if the concern was the client C, presenting a legitimate AT (ATr), which was issued to for the client to access to a resource R, to an attacker's resource S, that can be used for S to access R, then would not having the aud in the AT and have the client verify the peer would thwart the attack in the first place? If the request to AT starts with S and the AS issues ATs, then it would not be useful for anything but to access S, so it is not super useful to access other resource - though it can be used to trick the user to do all sort of other stuff. If the concern was that after the token has been obtained by the attacker, how to prevent it from being used, then notion of named/registered token (in contrast with bearer token) is needed. PoP is one way of doing it. Am I missing something? Nat 2015-03-18 10:31 GMT+09:00 Justin Richer : > I also drafted a more generalized mechanism (that was much less WS-*-y) > for doing an arbitrary token swap: > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > Phil had pretty much the same idea separately. > > Personally, I still think that the token-exchange draft needs to use a > syntactical mechanism like this instead of something so strictly tied to > the assertion formats. > > =E2=80=94 Justin > > On Mar 17, 2015, at 8:28 PM, John Bradley wrote: > > Security Token Service (STS) Sorry it is WS-* speak > http://en.wikipedia.org/wiki/Security_token_service > > You can emulate some of it with the assertions extension. > > The WG has a document as a starting position for a more general approach. > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 > > > Brian Campbell and I also documented our take on it for discussion. > https://tools.ietf.org/html/draft-campbell-oauth-sts-01 > > At the moment they don't really take into account issuing PoP tokens in > exchange but I expect that would be added as a WG document progresses. > > It is on the WG to do list. > > John B. > > On Mar 17, 2015, at 8:01 PM, Bill Mills wrote: > > STS? > > > > On Tuesday, March 17, 2015 2:40 PM, John Bradley > wrote: > > > This is fun:) > > I might ask what part of a OAuth 1.0a token is the user credential. Tha= t > is a slippery idea in itself. The token is a reference to some notion of > identity (in some cases) that needs to be dereferenced anyway. > > So in the same way a POP JWT access token in OAuth 2 that may indeed > contain claims about the subject would need to be exchanged at a AS for a > new token containing claims about the subject and the new presenter, or > depending on the security model it could be included directly in a new se= lf > signed AT. > > From a enterprise policy point of view having a REST like STS > functionality is I think the right long term answer. > > John B. > > > > On Mar 17, 2015, at 6:32 PM, Bill Mills wrote: > > In practice one of the drawbacks of the Oauth 1.0a tokens was that they > were not proxyable and so a connection to the edge then means you have to > unwrap that and make a new internal token to be usedwhich isn't as good a= s > the actual user credential. > > > > On Tuesday, March 17, 2015 2:26 PM, John Bradley > wrote: > > > PoP tokens need to be presented with a proof the presenter knows the > secret. That is the same principal as in OAuth 1.0a with needing to show > knowledge of the "token secret". > > I don't know what you mean by proxies internally. If the RS needs > another token to access a resource it should use the assertion flow and > authenticate itself to get another token based on the access token. > Passing around a PoP token as a bearer token is insecure/bad. > > In OAuth 1.0a because of the tight relationship between the "Service > Provider" and the "Protected Resource" people would be less likely to try > it but because the protected resource knows the "token secret" it could > still do lots of unexpected bad things. > > Proxying access tokens is not something RS should do, they need to be > exchanged at a AS for a new AT with the correct rights and optionally > binding it to a new PoP key. > > John B. > > > > On Mar 17, 2015, at 6:14 PM, Bill Mills wrote: > > > Yes. There's still the open question of whether/how PoP tokens can be > proxied internally within a site though. If they can be proxied then it > goes back to unsolved. > > > > On Tuesday, March 17, 2015 2:12 PM, John Bradley > wrote: > > > Or by OAuth 2 PoP. > > > On Mar 17, 2015, at 6:00 PM, Bill Mills wrote: > > "Yes but it is custom. People are inventing structured scopes like > "aud:https://foo.com", and that potentially doesn't solve the security > issue if a client just passes on the scopes it receives in the error > response, the bad RS just adds a scope for the good RS." > > This isn't solved by "aud", it is solved by OAuth 1.0a though.... > > > > > On Tuesday, March 17, 2015 1:54 PM, John Bradley > wrote: > > > Yes but it is custom. People are inventing structured scopes like > "aud:https://foo.com", and that potentially doesn't solve the security > issue if a client just passes on the scopes it receives in the error > response, the bad RS just adds a scope for the good RS. > > The client then potentially needs to understand the custom structures > scopes of every AS it might deal with. > > I think that would lead to lots of problems trying to make that a pattern > long term. At teh moment yes you can do it with a scope as long as the > client and AS both understand what is going on. > > > We added "aud" as a separate parameter for PoP as the token format for > different RS might be different as well as the symmetric pop keys needin= g > to be encrypted with different keys. > Yes we could have invented a special scope to carry the audience but a > separate parameter was much cleaner. > > I know some people have started using "aud" as a way to communicate the > resource when a scope applies to multiple RS but they may take different > token formats JWT vs opaque etc. > > Brian commented that the "aud" parameter may be useful beyond PoP so we > might want to think about documenting it in it's own mini spec, if I > understood him correctly. > > I think that may not be a bad idea as we are also planning on using it in > NAPPS. > > John B. > > On Mar 17, 2015, at 5:39 PM, Bill Mills wrote: > > I don't think it's "overloading scope names" to use them that way. The > aud value(s) could as easily be carried in scope as anywhere. Nothing sa= ys > a scope can't be "https://foo.com", and that Foo.com > requires that scope to be present for a token to be accepted. I would no= t > make it foo.com-read-mail for example. > > If it's more convenient to put it in aud I can accept that, but it's the > same functionality and can be implemented in scopes now. > > > > On Tuesday, March 17, 2015 12:41 PM, John Bradley > wrote: > > > People have been overloading scope names to create implicit audience. > > The problem is that clients need to know via some magic method that you > need to ask for scope "purple" to get write access to RS 2. > > Having an explicit "aud" parameter gives clients a way to communicate to > the AS what RS they are asking for a token for. > > the security issue is that if a client discovers a API out via some out o= f > band mechanism the OAuth error code can tell the client go to AS X and as= k > for Scope Y. > > Unfortunately without POP tokens or at-least passing the URI of the RS to > the AS via "aud", a bad RS could get a legitimate client to give it a tok= en > that can be replayed at a legitimate RS. > > This was one of the issues that Eran Hammer-Lahav was particularly > concerned about. > > I think I proposed a "aud" parameter to the token endpoint back then as a > alternative to requiring HMAC tokens, but that got lost in the confusion = at > the time. > > At that time though people were not yet thinking about interoperable OAut= h > API, only relatively tightly bound clients that were preconfigured for t= he > API endpoints they were using. > > In Health and other places we are starting to see standard clients that > discover API endpoints and configure themselves based on a users Identity > to use a arbitrary OAuth AS, moving into federation of AT. > > That is one of the reasons POP will be important, as it prevents RS from > misusing federated tokens by presenting them at other RS. > > The simplest thing to do is have the client say what RS it is trying to > access explicitly (The "aud" parameter), and including an audience in the > AT. to protect against malicious RS. > > PoP is the step up that also protects against tokens being intercepted an= d > replayed by another client. > > John B. > > On Mar 17, 2015, at 4:10 PM, Bill Mills wrote: > > This may have been hashed out already and I missed it, but "aud" just > becomes another kind of scope, correct? > > > > > On Tuesday, March 17, 2015 8:50 AM, John Bradley > wrote: > > > You could do that, but it is probably safer for the AS to know what RS it > can issue tokens for and refuse to issue a token for RS A to a client > asking for a token with RS X as the aud. > > John B. > > On Mar 16, 2015, at 8:27 PM, Dixie Baker > wrote: > > The threat that RFC6819 4.6.4 describes is when a client obtains an AT an= d > then sends it to a counterfeit RS, which then uses the AT to access > resources from a legitimate RS, on the end-user's behalf. > > The suggested countermeasure is a bit difficult to interpret: "Associate > the endpoint URL of the resource server the client talked to with the > access token (e.g., in an audience field) and validate the association at= a > legitimate resource server. The endpoint URL validation policy may be > strict (exact match) or more relaxed (e.g., same host). This would requi= re > telling the authorization server about the resource server endpoint URL i= n > the authorization process." > > As I read this, the suggestion is to have the client pass the URL of the > bad RS in the request to the AS (using the audience field). The AS then > would include that RS URL in the AT. Then, when the client passes the AT > to the bad RS, and it passes it on to the good RS, the good RS will check > the audience field, compare that URL with its own, and refuse the request= . > > -Dixie > > > > Dixie B. Baker, Ph.D. > Senior Partner > Martin, Blanck and Associates > Office (Redondo Beach, CA): 310-791-9671 > Mobile: 310-279-2579 > > On Mar 16, 2015, at 11:39 AM, John Bradley wrote: > > Brian and I were talking about "aud" used as a parameter to the token > endpoint when using a code or refresh token to indicate what RS the > resulting AT will be used at. > > Sending a audience in the AT wouldn't help prevent the attack being > discussed, though it may stop other sorts of attacks if the RS can tell = if > a AT was issued for it or another RS. > > In PoP having the AS check that you are sending the AT to the correct RS > is less important as the AT if stolen can't be used to replay against the > real AS. > > Though depending on the app the bogus RS feeding the app the wrong info > may well be a problem as well. > > John B. > > On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt > wrote: > > I don't think putting an aud into an AT will help to prevent counterfeit > RSs (as long as the aud is nit directly derived from the original URL use= d > by the client to invoke the counterfeit RS. as long as the aud is a > symbolic name of any kind, the counterfeit RS will accept ATs for the > legitimate RS and just (ab)use it. > > POP on the contrary helps since the counterfeit RS, in order to send a > message to the legitimate RS, needs to produce a new digitally signed > message using the correct secret, which it doesn't know. > > kind regards, > Torsten. > > > > Am 16.03.2015 um 17:40 schrieb Dixie Baker >: > > Using the "aud" parameter makes sense to me. Good suggestion. > > Authenticating the client to the RS would not address the counterfeit RS > threat. > > -Dixie > > > Dixie B. Baker, Ph.D. > Senior Partner > Martin, Blanck and Associates > Office (Redondo Beach, CA): 310-791-9671 > Mobile: 310-279-2579 > > On Mar 16, 2015, at 6:43 AM, Brian Campbell > wrote: > > We've used "aud" (optionally) with OAuth 2 and bearer tokens to help > identify the RS to whom the AT should be issued. It is useful but it's > mostly about getting format/content/etc of the AT correct for the RS rath= er > than it is about preventing possible AT leaks. > > I do think an "aud(iance)" parameter at both token and authorization > endpoints would have utility beyond the POP work. So defining it > independently might make sense. > > On Sun, Mar 15, 2015 at 11:34 AM, John Bradley wrote: > > In POP key distribution we do introduce a "audiance" parameter to the > token_endpoint. > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#sect= ion-3.1 > > It would be possible to have a small spec to define using "aud" with > bearer tokens, however that would be undefined behaviour at this point. > > I don't know of any clients that would try to access a RS server and then > besed on the error response try and get a access token from the AS > specified in the error. > > In POP we are trying to both protect agains that attack and more common > ones like doing a MiM to intercept the AT or the RS being hacked and > leaking the token. > > Using "aud" with bearer tokens would be useful, but probably won't stop > the majority of possible AT leaks. > > John B. > > > On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt > wrote: > > Hi Josh, > > I'm not aware of a common practice to use such a parameter. The WG is > instead heading towards authenticated requests to the resource server (se= e > https://tools.ietf.org/html/rfc6819#section-5.4.2). > > Please take a look onto > http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further > drafts on this topic. > > kind regards, > Torsten. > > Am 03.03.2015 um 18:27 schrieb Josh Mandel: > > Hi All, > > In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource > Server"), RFC6819 describes a threat where a counterfeit resource server > tricks a client into obtaining and sharing an access token from a > legitimate authorization server. One of the proposed mitigations involves= : > "telling the authorization server about the resource server endpoint URL = in > the authorization process." > > In other words, this mitigation would ask the client to pass an > additional parameter when redirecting to the Authorization server's > "authorize" URL, effectively something like: > > https://auth-server/authorize? > response_type=3Dcode& > client_id=3D123& > state=3D456& > scope=3Dread-all& > redirect_uri=3Dhttps://app-server/after-auth& > *resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com > * > > (And if the authorization server saw a value it didn't like in the final > parameter, it would reject the request.) > > This is obviously not appropriate in every authorization scenario, but > it is useful anytime there's a discovery process by which apps learn abou= t > authorization servers from resource servers. Since it's something of a > common need, I wanted to see if there was any common practice in how to > name this parameter, or whether it's worth registering a standard extensi= on > at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtm= l > . (I don't see one there now -- possibly I'm just missing it.) > > If so, what should it be called? The name I used in the example above is > a bit verbose :-) > > Best, > > Josh > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > 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 > > > > > > > > > > > > > > > > > > > _______________________________________________ > 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 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c30864e5a7430511ee2751 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry to come in so late, and I admit that I have just ski= mmed the thread, but if the concern was the client C, =C2=A0presenting a le= gitimate AT (ATr), which was issued to for the client to access to a resour= ce R, to an attacker's resource S, that can be used for S to access R, = then would not having the aud in the AT and have the client verify the peer= would thwart the attack in the first place?=C2=A0

If th= e request to AT starts with S and the AS issues ATs, then it would not be u= seful for anything but to access S, so it is not super useful to access oth= er resource - though it can be used to trick the user to do all sort of oth= er stuff.=C2=A0

If the concern was that after the to= ken has been obtained by the attacker, how to prevent it from being used, t= hen notion of named/registered token (in contrast with bearer token) is nee= ded. PoP is one way of doing it.=C2=A0

Am I = missing something?=C2=A0

Nat

2015-03-18 10:31 GMT+09:00 = Justin Richer <jricher@mit.edu>:
I also drafted a more generalized = mechanism (that was much less WS-*-y) for doing an arbitrary token swap:

Phil had pretty much the same idea se= parately.=C2=A0

Personally, I still think that the= token-exchange draft needs to use a syntactical mechanism like this instea= d of something so strictly tied to the assertion formats.

=C2=A0=E2=80=94 Jus= tin

On Mar 17, 2015, at 8:28 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:<= /div>
Security Token Service (S= TS) =C2=A0 Sorry it is WS-* speak=C2=A0http://en.wikipedia.org/wiki/= Security_token_service

You can emulate some of it wi= th the assertions extension.=C2=A0

The WG has a do= cument as a starting position for a more general approach.



At the = moment they don't really take into account issuing PoP tokens in exchan= ge but I expect that would be added as a WG document progresses.
=
It is on the WG to do list.

John B.=

On Mar 17, 2015, at 8:01= PM, Bill Mills <wmills_92105@yahoo.com> wrote:

STS?



On Tuesday,= March 17, 2015 2:40 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
=

This is fun:)

I m= ight ask what part of a OAuth 1.0a token is the user credential. =C2=A0 Tha= t is a slippery idea in itself.=C2=A0 The token is a reference to some noti= on of identity (in some cases) that needs to be dereferenced anyway.
<= div>
So in the same way a POP JWT access token= in OAuth 2 that may indeed contain claims about the subject would need to = be exchanged at a AS for a new token containing claims about the subject an= d the new presenter, or depending on the security model it could be include= d directly in a new self signed AT.

From a enterprise policy point of view having a REST like STS functionalit= y is I think the right long term answer.

John B.



On Mar= 17, 2015, at 6:32 PM, Bill Mills <wmills_92105@yahoo.c= om> wrote:

In practice one of the drawbacks of the Oauth 1.0a tokens was tha= t they were not proxyable and so a connection to the edge then means you ha= ve to unwrap that and make a new internal token to be usedwhich isn't a= s good as the actual user credential.=C2=A0

=

<= div style=3D"font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucid= a Grande,sans-serif;font-size:12px">
=
On Tuesday, March 17, 2015 2:26 PM,= John Bradley <ve7jtb@ve7jtb.com> wrote:


PoP tokens need to be presented with a proof the presenter knows the secr= et.=C2=A0 That is the same principal as in OAuth 1.0a with needing to show = knowledge of the "token secret".

I don't know what you mean by proxies internally. =C2=A0 If the RS ne= eds another token to access a resource it should use the assertion flow and= authenticate itself to get another token based on the access token.
<= div>Passing around a PoP token as a bearer token is insecure/bad.

In OAuth 1.0a because of the tight relations= hip between the "Service Provider" and the "Protected Resour= ce" people would be less likely to try it but because the protected re= source knows the "token secret" it could still do lots of unexpec= ted bad things.

Proxying access tok= ens is not something RS should do, they need to be exchanged at a AS for a = new AT with the correct rights and optionally binding it to a new PoP key.<= /div>

John B.



=
On Mar 17, 2015, at 6:14 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Yes.=C2=A0 T= here's still the open question of whether/how PoP tokens can be proxied= internally within a site though.=C2=A0 If they can be proxied then it goes= back to unsolved.



= On Tuesday, March 17, 2015 2:12 PM, John Bradley <= ve7jtb@ve7jtb.com> wrote:

Or by OAuth 2 Po= P. =C2=A0 =C2=A0


=
On Mar 17, 2015, at 6:00 PM, Bill Mills= <wmills_92105@yahoo.com> wrote:

"Yes but it is custom.=C2=A0= People are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't= solve the security issue if a client just passes on the scopes it receives= in the error response, the bad RS just adds a scope for the good RS."=

This isn't solved by "aud", it is solved= by OAuth 1.0a though....
=C2=A0


On Tues= day, March 17, 2015 1:54 PM, John Bradley <ve7jtb@ve7jtb.com= > wrote:


Yes but it is custom.=C2=A0 People are invent= ing structured scopes like "aud:https://foo.com", and that= potentially doesn't solve the security issue if a client just passes o= n the scopes it receives in the error response, the bad RS just adds a scop= e for the good RS.

The client then potent= ially needs to understand the custom structures scopes of every AS it might= deal with.

I think that would lead= to lots of problems trying to make that a pattern long term. =C2=A0 At teh= moment yes you can do it with a scope as long as the client and AS both un= derstand what is going on.


We added "aud" as a separate parameter for = PoP as the token format for different RS might be different as well as the = symmetric =C2=A0pop keys needing to be encrypted with different keys.
=
Yes we could have invented a special scope to carry the audience but a= separate parameter was much cleaner.

I know some people have started using "aud" as a way to commun= icate the resource when a scope applies to multiple RS but they may take di= fferent token formats JWT vs opaque etc.

Brian commented that the "aud" parameter may be useful beyo= nd PoP so we might want to think about documenting it in it's own mini = spec, if I understood him correctly.

I think that may not be a bad idea as we are also planning on using it in= NAPPS.

John B.

On Mar 17, 2015, at= 5:39 PM, Bill Mills <wmills_92105@yahoo.com> wr= ote:

I don't think it's "overloading scope names" to use th= em that way.=C2=A0 The aud value(s) could as easily be carried in scope as = anywhere.=C2=A0 Nothing says a scope can't be "https://foo.com= ", and that Foo.com requires that scope to be present for a= token to be accepted.=C2=A0 I would not make it foo.com-read-mail = for example.

<= /div>
If it's more convenient to put it in aud I = can accept that, but it's the same functionality and can be implemented= in scopes now.


On Tuesday, March 17, 2015 12:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


People have been= overloading scope names to create implicit audience. =C2=A0=C2=A0

The problem is that clients need to know via some= magic method that you need to ask for scope "purple" to get writ= e access to RS 2.

Having an explicit &quo= t;aud" parameter gives clients a way to communicate to the AS what RS = they are asking for a token for.=C2=A0

the security issue is that if a client discovers a API out= via some out of band mechanism the OAuth error code can tell the client go= to AS X and ask for Scope Y. =C2=A0

Unfortunately without POP tokens or at-least passing the URI of the RS to= the AS via "aud", a bad RS could get a legitimate client to give= it a token that can be replayed at a legitimate RS.

This was one of the issues that Eran Hammer-Lahav was par= ticularly concerned about. =C2=A0

I= think I proposed a "aud" parameter to the token endpoint back th= en as a alternative to requiring HMAC tokens, but that got lost in the conf= usion at the time.

At that time tho= ugh people were not yet thinking about interoperable OAuth API, =C2=A0only = relatively tightly bound clients that were preconfigured for the API endpoi= nts they were using.

In Health and = other places we are starting to see standard clients that discover API endp= oints and configure themselves based on a users Identity to use a arbitrary= OAuth AS, moving into federation of AT.

That is one of the reasons POP will be important, as it prevents RS f= rom misusing federated tokens by presenting them at other RS.
The simplest thing to do is have the client say = what RS it is trying to access explicitly (The "aud" parameter), = and including an audience in the AT. =C2=A0to protect against malicious RS.=

PoP is the step up that also prote= cts against tokens being intercepted and replayed by another client.
<= div>
John B.

On Mar 17, 2015, at 4:10 PM= , Bill Mills <wmills_92105@yahoo.com> wrote:
This = may have been hashed out already and I missed it, but "aud" just = becomes another kind of scope, correct?
=



= On Tuesday, March 17, 2015 8:50 AM, John Bradley <= ;ve7jtb@ve7jtb.com> wrote:

You could = do that, but it is probably safer for the AS to know what RS it can issue t= okens for and refuse to issue a token for RS A to a client asking for a tok= en with RS X as the aud.

John B.
On Mar 16, 2015, a= t 8:27 PM, Dixie Baker <Dixie.Baker@martin-blanc= k.com> wrote:

=
The threat = that RFC6819 4.6.4 describes is when a client obtains an AT and then sends = it to a counterfeit RS, which then uses the AT to access resources from a l= egitimate RS, on the end-user's behalf. =C2=A0

<= /div>
The suggested countermeasure is a bit difficult to interpret: =C2= =A0"Associate the endpoint URL of the resource server the client talke= d to with the access token (e.g., in an audience field) and validate the as= sociation at a legitimate resource server.=C2=A0 The endpoint URL validatio= n policy may be strict (exact match) or more relaxed (e.g., same host).=C2= =A0 This would require telling the authorization server about the resource = server endpoint URL in the authorization process." =C2=A0
As I read this, the suggestion is to have the c= lient pass the URL of the bad RS in the request to the AS (using the audien= ce field).=C2=A0 The AS then would include that RS URL in the AT.=C2=A0 The= n, when the client passes the AT to the bad RS, and it passes it on to the = good RS, the good RS will check the audience field, compare that URL with i= ts own, and refuse the request. =C2=A0

<= div>-Dixie


=

Dixie B. Baker, Ph.D= .
Senior Partner
Martin, Blanck and Ass= ociates
Office (Redondo Beach, CA): =C2=A0310-791-9671Mobile: =C2=A0310-279-2579

On Mar 16, 2015, at 11:39 AM, John Bradley <= ;ve7jtb@ve7jtb.com> wrote:

Brian and I were talking about "aud"= ; used as a parameter to the token endpoint when using a code or refresh to= ken to indicate what RS the resulting AT will be used at.

Sending a audience in the AT wouldn't help prevent the= attack being discussed, =C2=A0though it may stop other sorts of attacks if= the RS can tell if a AT was issued for it or another RS.

In PoP having the AS check that you are sending the = AT to the correct RS is less important as the AT if stolen can't be use= d to replay against the real AS.

Th= ough depending on the app the bogus RS feeding the app the wrong info may w= ell be a problem as well.

John B.

On Mar 16, = 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodders= tedt.net> wrote:

I don't think putting an aud into a= n AT will help to prevent counterfeit RSs (as long as the aud is nit direct= ly derived from the original URL used by the client to invoke the counterfe= it RS. as long as the aud is a symbolic name of any kind, the counterfeit R= S will accept ATs for the legitimate RS and just (ab)use it.

POP on the contrary helps since the counterfeit R= S, in order to send a message to the legitimate RS, needs to produce a new = digitally signed message using the correct secret, which it doesn't kno= w.

kind regards,
Torsten.=



Am 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com>:

Using the "aud" parameter makes sense to me.=C2=A0 Good s= uggestion.

Authenticating the client to t= he RS would not address the counterfeit RS threat.=C2=A0

-Dixie

=C2=A0=
Dixie B. Baker, Ph.D= .
Senior Partner
Martin, Blanck and Ass= ociates
Office (Redondo Beach, CA): =C2=A0310-791-9671Mobile: =C2=A0310-279-2579

On Mar 16, 2015, at 6:43 AM, Brian Campbell &l= t;bcampbell@pingidentity.com> wrote:

We've use= d "aud" (optionally) with OAuth 2 and bearer tokens to help ident= ify the RS to whom the AT should be issued. It is useful but it's mostl= y about getting format/content/etc of the AT correct for the RS rather than= it is about preventing possible AT leaks.

I do think an "aud(iance)" parameter at both token and= authorization endpoints would have utility beyond the POP work. So definin= g it independently might make sense.

On Sun, Mar 15, 2015 at 11:34 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In POP key distribution w= e do introduce a "audiance" parameter to the token_endpoint.=C2= =A0http= s://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.= 1

It would be possible to have a smal= l spec to define using "aud" with bearer tokens, however that wou= ld be undefined behaviour at this point.

I don't know of any clients that would try to access a RS server = and then besed on the error response try and get a access token from the AS= specified in the error.

In POP we = are trying to both protect agains that attack and more common ones like doi= ng a MiM to intercept the AT or the RS being hacked and leaking the token.<= /div>

Using "aud" with bearer t= okens would be useful, but probably won't stop the majority of possible= AT leaks.

John B.
<= div>

On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=
=20 =20 =20
Hi Josh,

I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org= /html/rfc6819#section-5.4.2).

Please take a look onto http://tools.ietf.org/h= tml/draft-ietf-oauth-pop-architecture and further drafts on this topic.

kind regards,
Torsten.

Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,

In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource Server"), RFC6819 describes a threat where a counterfeit resource server tricks a client into obtaining and sharing an access token from a legitimate authorization server. One of the proposed mitigations involves: "telling the authorization server about the resour= ce server endpoint URL in the authorization process."

In other words, this mitigation would ask the client to pass an additional parameter when redirecting to the Authorization server's "authorize" URL, effectively= something like:

response_type=3Dcode&
client_id=3D123&
state=3D456&
scope=3Dread-all&
resource_server_that_told_me_to_authorize_here=3Dhttps://attacker.com

(And if the authorization server saw a value it didn't lik= e in the final parameter, it would reject the request.)

This is obviously not appropriate in every authorization scenario, but it is useful anytime there's a discovery proces= s by which apps learn about authorization servers from resource servers. Since it's something of a common need, I wanted to see if there was any common practice in how to name this parameter, or whether it's worth registering a standard extension at=C2=A0http://www.iana.org/assignments/oauth-parameters/oauth-paramete= rs.xhtml . (I don't see one there now -- possibly I'm just missing= it.)

If so, what should it be called? The name I used in the example above is a bit verbose :-)

Best,

=C2=A0 Josh


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

_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" href=3D"https://www.ietf.org/mailman/list= info/oauth" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth


__________________________________________= _____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>









=



=






=






<= /div>
_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth


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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--001a11c30864e5a7430511ee2751-- From nobody Sun Mar 22 23:41:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFE61A88D6 for ; Sun, 22 Mar 2015 23:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 NR4sOrS2-4pD for ; Sun, 22 Mar 2015 23:41:11 -0700 (PDT) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7E81A88DB for ; Sun, 22 Mar 2015 23:41:11 -0700 (PDT) Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKVQ+1hjnvDn+ggscyb7/pOWlnH5VnYK1D@postini.com; Sun, 22 Mar 2015 23:41:11 PDT Received: by iecvj10 with SMTP id vj10so28886023iec.0 for ; Sun, 22 Mar 2015 23:41:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=qz78TyXZW/Wd/9JwVHbuydQQ/FkDOAjDAkoX/m4g7Zc=; b=LrRY0dWBHw4mBKjInzxchP8cqezqEyAAUKxkJCxuKWCe8JfsiWZlEtF8Oob39/UFgM AoN2khfKb5bT2T74wfLrLTHrHMwXgE1ApMcIc56XxpP6EkzkDx4Wbu6AL48W+8YOAipn v2VDsgconepYWXQBQSDX87WLGdoP4QgvJnGWclavat4+L9IsOCgLGyyXYiNeE5owRjbA vv/8NDuLqTb3IHFgL11shm1+ed+2jUBjr16rM3qPHEBA196bvwqyhiK2ht5PLtQHbDMZ jS6Od5UKlwcFfeJWhW2ROqSUBMXoOsv8Gu/qgYtoDhHAXgaPTYOwPwVGrcr/vpLUrx2W /TDg== X-Gm-Message-State: ALoCoQmiojEhWmtWBi1aOG3wMivIYFwjz6LsmaKjpco3LobABB3wioAdqXygYa4ajPZYNJHGoNuIdGEEMuiJUKJVFl7XFgLWSDUF5cnbxLhaX3TgjxwRhUF9rkncB4NQ8RaGh7amx3aC X-Received: by 10.50.78.9 with SMTP id x9mr12259735igw.44.1427092870311; Sun, 22 Mar 2015 23:41:10 -0700 (PDT) X-Received: by 10.50.78.9 with SMTP id x9mr12259622igw.44.1427092868221; Sun, 22 Mar 2015 23:41:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Sun, 22 Mar 2015 23:40:38 -0700 (PDT) From: Brian Campbell Date: Mon, 23 Mar 2015 01:40:38 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=089e0115f63878e7a10511eef32c Archived-At: Subject: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 06:41:12 -0000 --089e0115f63878e7a10511eef32c Content-Type: text/plain; charset=UTF-8 Do folks in the WG think there'd be utility in having a way to identity the finger/thumbprint of a key in the cnf claim. A presenter might, for example, present the JWT along with a public JWK and some proof-of-possession of that JWK. And the JWK would be bound to the JWT via the thumbprint, which is more space efficient (with respect to the JWT anyway) than the full JWK. --089e0115f63878e7a10511eef32c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do folks in the WG think there'd be utility in having = a way to identity the finger/thumbprint of a key in the cnf claim. A presen= ter might, for example, present the JWT along with a public JWK and some pr= oof-of-possession of that JWK.=C2=A0 And the JWK would be bound to the JWT = via the thumbprint, which is more space efficient (with respect to the JWT = anyway) than the full JWK.


--089e0115f63878e7a10511eef32c-- From nobody Sun Mar 22 23:41:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F81A88EE for ; Sun, 22 Mar 2015 23:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 GxMYde6cvvej for ; Sun, 22 Mar 2015 23:41:31 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623E91A88E2 for ; Sun, 22 Mar 2015 23:41:31 -0700 (PDT) Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKVQ+1muSDYsTWokKLPXSggJ9o3ySOqWGR@postini.com; Sun, 22 Mar 2015 23:41:31 PDT Received: by igbud6 with SMTP id ud6so34067620igb.1 for ; Sun, 22 Mar 2015 23:41:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=z/qiPFafZfUepJ2xXrdiYiY0q8u0rtirVjyExl0K7Fw=; b=hkbZWOoEQUs83waoFi0olLJHQfQ3SbJenV/YRoKwu4fRg5oQMWy8aegBI7DdZ7PdF0 Y0TvGYEPeDrJQ3uebJaRn6cbknOiybdTdgOqekKzUIxR+BXAULuVXICElF09is4EIJ/a z+1RUiepFsJTH0Plst3HjiKnajlGrljtPb6XnnAI6Um5Zc3SX6YT28IwiGLcR2ykY/0i PXy8Ic8cv5hiIhdkzCn4/r2v1kSry7inI0hP9T8QOg0Z+0Z6WbaZKIjKAIa0JjbqlTrj 1gMH2XAedI+vY+e7TwtsUPmvXaBQwlmtqF880PFyM0q3IopXRPic7knumfJY3it9/AYY Kevg== X-Gm-Message-State: ALoCoQmTLG9ZiKkpKYD2mOc5AR/jl8SWapqgZ6/UzVoe2nOQaiv1y/wYMzeLRKjriq+JD3WF5jWPCWwaVTxpTDHig0yjBfcoazfYjQ5gdnBqsfezle6jVfspPDRSb1rzcB8JbTkux2zV X-Received: by 10.50.32.7 with SMTP id e7mr12303528igi.21.1427092890445; Sun, 22 Mar 2015 23:41:30 -0700 (PDT) X-Received: by 10.50.32.7 with SMTP id e7mr12303522igi.21.1427092890376; Sun, 22 Mar 2015 23:41:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Sun, 22 Mar 2015 23:40:58 -0700 (PDT) From: Brian Campbell Date: Mon, 23 Mar 2015 01:40:58 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=047d7b10cbf1caf4650511eef4be Archived-At: Subject: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 06:41:32 -0000 --047d7b10cbf1caf4650511eef4be Content-Type: text/plain; charset=UTF-8 When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? --047d7b10cbf1caf4650511eef4be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When the JWT is itself encrypted as a JWE, would it n= ot be reasonable to have a symmetric key be represented in the cnf claim wi= th the jwk member as an unencrypted JSON Web Key?=C2=A0

Is su= ch a possibility left as an exercise to the reader? Or should it be more ex= plicitly allowed or disallowed?


--047d7b10cbf1caf4650511eef4be-- From nobody Sun Mar 22 23:41:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9F1A88DB for ; Sun, 22 Mar 2015 23:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Zc51rH-d1QAO for ; Sun, 22 Mar 2015 23:41:54 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B6E1A1B39 for ; Sun, 22 Mar 2015 23:41:54 -0700 (PDT) Received: from mail-ig0-f170.google.com ([209.85.213.170]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKVQ+1sntz++vVvVjwOkEbQzsM8y5Q3z3L@postini.com; Sun, 22 Mar 2015 23:41:54 PDT Received: by igcqo1 with SMTP id qo1so30831694igc.0 for ; Sun, 22 Mar 2015 23:41:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=O48g7d8wHgNjLWb5rv9lg/GgMe7KyJcXMqLbFI7XvOo=; b=GdbY8Dj/We3WaJd5z2pTQBwx6z0S/niq9GtX2pHvjf3NxGhIu9INuGQHuHyHp5EAyw UjiP85AjoLf7FftH/lJP6aeygEtb0rZ0oX8eoWQGcFEQFMeD8fXfSQ7hAlppUD/5l+RG ORqMGkNXGAsCrfbCBCW2ICiPUWioPcwzKjEC30K/87QXYmvRs+KZGHkITzfXOqgDvA8Z FocSFTbynjDVFQgBsC/xwaupmUnMQQdXK1e5iUYtrpy+TmlNM1SeW8v2ZFgIL23c9pya YQFdqP3H8x73LcAGtitzgsYoRNjjcAUhyDOzIhAyqo+4do9ctwTItHpPjbXLjOYvCRU6 Tyqg== X-Gm-Message-State: ALoCoQnVqA3hdhwChPjsMtxJ1eNeQ/fhQ9S4Ns1TebdnXGPvkkl24Veq9O/AtYQy6CqPcsP69voBK2jZTzA7Uje0k/9vCZ+T68PNz+BKi+aeNXQp7/ss+Hg3G+01wGNwXHE0D46NykrQ X-Received: by 10.50.1.48 with SMTP id 16mr12511207igj.45.1427092914222; Sun, 22 Mar 2015 23:41:54 -0700 (PDT) X-Received: by 10.50.1.48 with SMTP id 16mr12511204igj.45.1427092914136; Sun, 22 Mar 2015 23:41:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Sun, 22 Mar 2015 23:41:23 -0700 (PDT) From: Brian Campbell Date: Mon, 23 Mar 2015 01:41:23 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=047d7bdc12b035a5ae0511eef61f Archived-At: Subject: [OAUTH-WG] jwk as member for both asymmetric and symmetric in proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 06:41:56 -0000 --047d7bdc12b035a5ae0511eef61f Content-Type: text/plain; charset=UTF-8 Is there some reason that the "cnf" claim uses a member named "jwk" for both the asymmetric case where its value is a JWK with a public key and the symmetric case where its value is the JWE encrypted oct JWK (sections 3.1 and 3.2 )? https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3.2 and I realize that section 3.2 describes how to distinguish between the two cases by the type of the member value. But it seems a bit awkward and I kind of expected two different member names for the two different cases. Maybe "ewk" or even just "jwe" for the encrypted key case? Note that 3.2 also mentions the '"jwk" claim' which should probably say the '"jwk" member". "cnf" is the claim and "jwk" is a member of that claim value. --047d7bdc12b035a5ae0511eef61f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there some reason that the "cnf" claim u= ses a member named "jwk" for both the asymmetric case where its v= alue is a JWK with a public key and the symmetric case where its value is t= he JWE encrypted oct JWK (sections 3.1 and 3.2)?

https://tools.ietf.org/html/draft-i= etf-oauth-proof-of-possession-02#section-3.2 and

I r= ealize that section 3.2 describes how to distinguish between the two cases = by the type of the member value. But it seems a bit awkward and I kind of e= xpected two different member names for the two different cases.

May= be "ewk" or even just "jwe" for the encrypted key case?=

Note that 3.2 also mentions the '"jwk" cl= aim' which should probably say the '"jwk" member". &= quot;cnf" is the claim and "jwk" is a member of that claim v= alue.




--047d7bdc12b035a5ae0511eef61f-- From nobody Mon Mar 23 00:11:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697D31A88FD for ; Mon, 23 Mar 2015 00:11: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, SPF_PASS=-0.001] autolearn=ham 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 gtxNgeuqzDzQ for ; Mon, 23 Mar 2015 00:11:18 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 C3A4B1A8908 for ; Mon, 23 Mar 2015 00:11:18 -0700 (PDT) Received: by oiag65 with SMTP id g65so133510732oia.2 for ; Mon, 23 Mar 2015 00:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cW+MCnTSTwAKLsRcd+Ez4GK7id2Hb5h5ki8TTkTYiEQ=; b=FExUK0SsJbDZoooE58BotsJpY8Tge9OWC7CXzBx19L8R6pTkoavYVIYHMHAM8R5yz6 bUbTl/YPuSJnopzUyUhmscXmprbY1O5Yh3VlHYFYiwKhTHY2y/fxulP8GhhE4ae/al6d lzN+AVvRLVQI8hDkV3zxReE/Mn7czXH1MHEfTZITbI121M/nPMRBUhrwYHIZHWe1S4Kq /F5Vuo2/SYzNaTTFmcsmKe+kjaE070ox8V67/sH0Aadr8WgJCCblVPzW82FnCOHE8Wra BOdx5ESjoNSTg5d9/Q0DNikxYSlu1CPxZ34A8ACCrGAGMzlsgI/nHTtyRc4AmCyATOsk Gf1g== MIME-Version: 1.0 X-Received: by 10.202.63.132 with SMTP id m126mr69045188oia.33.1427094678303; Mon, 23 Mar 2015 00:11:18 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Mon, 23 Mar 2015 00:11:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 16:11:18 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113d660a5c7b1a0511ef5f11 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 07:11:20 -0000 --001a113d660a5c7b1a0511ef5f11 Content-Type: text/plain; charset=UTF-8 Would not kid do? Right, thumbprint has more semantics and has nice properties, but having too many ways is not good for interop. Nat 2015-03-23 15:40 GMT+09:00 Brian Campbell : > Do folks in the WG think there'd be utility in having a way to identity > the finger/thumbprint of a key in the cnf claim. A presenter might, for > example, present the JWT along with a public JWK and some > proof-of-possession of that JWK. And the JWK would be bound to the JWT via > the thumbprint, which is more space efficient (with respect to the JWT > anyway) than the full JWK. > > > > _______________________________________________ > 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 --001a113d660a5c7b1a0511ef5f11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would not kid do?=C2=A0
Right, thumbprint h= as more semantics and has nice properties, but having too many ways is not = good for interop.=C2=A0

Nat

2015-03-23 15:40 GMT+09:00 = Brian Campbell <bcampbell@pingidentity.com>:
Do folks in the WG think there= 'd be utility in having a way to identity the finger/thumbprint of a ke= y in the cnf claim. A presenter might, for example, present the JWT along w= ith a public JWK and some proof-of-possession of that JWK.=C2=A0 And the JW= K would be bound to the JWT via the thumbprint, which is more space efficie= nt (with respect to the JWT anyway) than the full JWK.



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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--001a113d660a5c7b1a0511ef5f11-- From nobody Mon Mar 23 00:25:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABA41A8927 for ; Mon, 23 Mar 2015 00:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 MoF_jhE7DeDP for ; Mon, 23 Mar 2015 00:25:14 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003: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 372361A8923 for ; Mon, 23 Mar 2015 00:25:14 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so116950212obd.3 for ; Mon, 23 Mar 2015 00:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4Gnz9g9VPGsTk8dSd/IRTUvkMfbE+MiPvUKXPca9i8U=; b=pdn6wLnDouUC8+udRf2TjYT9JAK8VlVNP/OGHS7Rz+qgT/uxHIuXhZGK6QXGkIFLMj z1iG9cJl/adbfHqVx/AFQ9yK9Wlf1J50GQKSOd8zAf2RHPKx8uYM2NBwEIM6+GWQ7qoa VUgsWASKaQfDjKfPtI4ke4YM6mzyXoPl6ni4Wukv0L4h8IQKqEVNbUkSZkufdQK+LSDg MLB78oq0N0+52cYCE8YbpxYcjcz9w46Uzl2wlztKDV2Z4AsyMQM9appZBXZefQiNxzHZ yyaO7dLNWuGlpli7y2jk6gYm3HMgjPhb1hE46GRn0TaluvSV6aFLjMEhEie4oE7MpMv4 bRLw== MIME-Version: 1.0 X-Received: by 10.182.242.106 with SMTP id wp10mr20247243obc.14.1427095513730; Mon, 23 Mar 2015 00:25:13 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Mon, 23 Mar 2015 00:25:13 -0700 (PDT) Date: Mon, 23 Mar 2015 16:25:13 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=e89a8ff2521a2815800511ef91d4 Archived-At: Subject: [OAUTH-WG] The use of sub in POP-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 07:25:15 -0000 --e89a8ff2521a2815800511ef91d4 Content-Type: text/plain; charset=UTF-8 Re: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3 I understand the use of sub in this section comes down from SAML but I feel that some separation between sub and presenter would be nice. For example, when I am presenting the token using an app that I installed on my iPhone, the presenter is that app and not me, while the sub still may be me. The app is the authorized presenter/party (azp) of the token. So my proposal is to use a claim like "azp" instead of "sub" to identify the presenter. Less overload would cause less confusion later, IMHO. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --e89a8ff2521a2815800511ef91d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Re:=C2=A0https://tools.ietf.org/html/draft-= ietf-oauth-proof-of-possession-02#section-3

I unders= tand the use of sub in this section comes down from SAML but I feel that so= me separation between sub and presenter would be nice.=C2=A0

=
For example, when I am presenting the token using an app that I = installed on my iPhone, the presenter is that app and not me, while the sub= still may be me. The app is the authorized presenter/party (azp) of the to= ken.=C2=A0

So my proposal is to use a claim like &= quot;azp" instead of "sub" to identify the presenter. Less o= verload would cause less confusion later, IMHO.=C2=A0

<= div>
--
Nat Sakimura (=3Dnat)
Ch= airman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--e89a8ff2521a2815800511ef91d4-- From nobody Mon Mar 23 00:29:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC52D1A8931 for ; Mon, 23 Mar 2015 00:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 TDAlcBwYZDAw for ; Mon, 23 Mar 2015 00:29:48 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1DB1A892F for ; Mon, 23 Mar 2015 00:29:48 -0700 (PDT) Received: from [80.187.109.131] (helo=[10.132.227.160]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1YZwny-0007Eu-Ft; Mon, 23 Mar 2015 08:29:46 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WZ24AKJ27RLQEUVAGP5H0K15LMNEOG" Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Mon, 23 Mar 2015 08:29:44 +0100 To: Nat Sakimura ,oauth Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] The use of sub in POP-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 07:29:51 -0000 ------WZ24AKJ27RLQEUVAGP5H0K15LMNEOG Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 +1 sounds reasonable to distinguish the software and the user. Am 23. März 2015 08:25:13 MEZ, schrieb Nat Sakimura : >Re: >https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3 > >I understand the use of sub in this section comes down from SAML but I >feel >that some separation between sub and presenter would be nice. > >For example, when I am presenting the token using an app that I >installed >on my iPhone, the presenter is that app and not me, while the sub still >may >be me. The app is the authorized presenter/party (azp) of the token. > >So my proposal is to use a claim like "azp" instead of "sub" to >identify >the presenter. Less overload would cause less confusion later, IMHO. > >-- >Nat Sakimura (=nat) >Chairman, OpenID Foundation >http://nat.sakimura.org/ >@_nat_en > > >------------------------------------------------------------------------ > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------WZ24AKJ27RLQEUVAGP5H0K15LMNEOG Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1

sounds reasonable to distinguish the software and the user.

Am 23. März 2015 08:25:13 MEZ, schrieb Nat Sakimura <sakimura@gmail.com>:
Re: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3

I understand the use of sub in this section comes down from SAML but I feel that some separation between sub and presenter would be nice. 

For example, when I am presenting the token using an app that I installed on my iPhone, the presenter is that app and not me, while the sub still may be me. The app is the authorized presenter/party (azp) of the token. 

So my proposal is to use a claim like "azp" instead of "sub" to identify the presenter. Less overload would cause less confusion later, IMHO. 

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


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

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------WZ24AKJ27RLQEUVAGP5H0K15LMNEOG-- From nobody Mon Mar 23 07:06:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE741A8AB6 for ; Mon, 23 Mar 2015 07:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 i7Oo1M-sOLA6 for ; Mon, 23 Mar 2015 07:06:16 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70901A8AC5 for ; Mon, 23 Mar 2015 07:06:15 -0700 (PDT) Received: from mail-ig0-f170.google.com ([209.85.213.170]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKVRAd11zm5TB5+cXl2MbmJx7+39W1dmiE@postini.com; Mon, 23 Mar 2015 07:06:15 PDT Received: by igcau2 with SMTP id au2so42960353igc.0 for ; Mon, 23 Mar 2015 07:06:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oETS/XIdgj01X9isyJ7O0noFNy4kRNEGHWClaWgrYrI=; b=PNT+dqFbBpdH2w7dGk/DqkvLmv7nQVsNQGhV2HUWQ136d+Cn/RNDoIBH84f+wVRJTm Knb58HPdMZ7TdxDyKY1isfTg0ARaL+AV1Kbl4HcNQIBU5at3bhnO0my2E7PvWcW2OY4k a3IFke7OfemssuKzuJ/apDI7JzZEYSufU88G6cr89NSS8w8pgPNlYUtNoY5Orx1h92C6 9kfubJJS2le9NE3B6JIT7oQ3gvlg/sEbFAYpm7rALytiWFg1vtQtjPoFQtXtgbMXlr8l 8x21QdFT8jRnI/A5/EaDsvOPp0RfTJWyTpUdfpxTa8BR5CFm5Tw57P/9ckSdS0w9uucJ tr/A== X-Gm-Message-State: ALoCoQkGGSCeQOR1/yiiKyB7lcPpwlCFXuWsHKirOfgGAfZF8bsZNfp5BI5yn8xdudQfCJrzLsytx3onJwP7jly0C+R9/gp4vys7SQd/fTIA3GPpMCt9EozfhctLuHL3s8C673AEZcK1 X-Received: by 10.50.109.228 with SMTP id hv4mr14841042igb.45.1427119575025; Mon, 23 Mar 2015 07:06:15 -0700 (PDT) X-Received: by 10.50.109.228 with SMTP id hv4mr14841009igb.45.1427119574842; Mon, 23 Mar 2015 07:06:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Mon, 23 Mar 2015 07:05:44 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 23 Mar 2015 09:05:44 -0500 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=089e013a214e4f9c250511f52b85 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] The use of sub in POP-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:06:20 -0000 --089e013a214e4f9c250511f52b85 Content-Type: text/plain; charset=UTF-8 +1 The JWT may well be about the sub but presented by some software component that should be independently identified. On Mon, Mar 23, 2015 at 2:25 AM, Nat Sakimura wrote: > Re: > https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3 > > I understand the use of sub in this section comes down from SAML but I > feel that some separation between sub and presenter would be nice. > > For example, when I am presenting the token using an app that I installed > on my iPhone, the presenter is that app and not me, while the sub still may > be me. The app is the authorized presenter/party (azp) of the token. > > So my proposal is to use a claim like "azp" instead of "sub" to identify > the presenter. Less overload would cause less confusion later, IMHO. > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e013a214e4f9c250511f52b85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

The JWT may well be about the sub bu= t presented by some software component that should be independently identif= ied.=C2=A0

On Mon, Mar 23, 2015 at 2:25 AM, Nat Sakimura <sakimura@gmail.com= > wrote:
Re:= =C2=A0https://tools.ietf.org/html/draft-ie= tf-oauth-proof-of-possession-02#section-3

I understa= nd the use of sub in this section comes down from SAML but I feel that some= separation between sub and presenter would be nice.=C2=A0

For example, when I am presenting the token using an app that I in= stalled on my iPhone, the presenter is that app and not me, while the sub s= till may be me. The app is the authorized presenter/party (azp) of the toke= n.=C2=A0

So my proposal is to use a claim like &qu= ot;azp" instead of "sub" to identify the presenter. Less ove= rload would cause less confusion later, IMHO.=C2=A0

--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
<= /div>

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


--089e013a214e4f9c250511f52b85-- From nobody Mon Mar 23 09:07:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032F01A92F5 for ; Mon, 23 Mar 2015 09:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 81fU9q56Go2F for ; Mon, 23 Mar 2015 09:07:36 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814DD1A923E for ; Mon, 23 Mar 2015 09:07:36 -0700 (PDT) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKVRA6R67PdEzUvrGje1FcTqT85BodSU24@postini.com; Mon, 23 Mar 2015 09:07:36 PDT Received: by ieclw3 with SMTP id lw3so39401559iec.2 for ; Mon, 23 Mar 2015 09:07:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=oaNG+HDhf4m1aJXk5bzUTeDAzjToR7HBEY4bXw+1WVc=; b=iw7OjZfznDuvYgh41SZ0925UcS1c0MPKlK37PksYi4dTcqjsEsSXq3YbXlfJgTzO/l QznbrEZoz355uGJ4gNkNYN4WqZjthStdfymx8+aJ6iYOVkCc9Dchu4TLZNgu+GQGhzF+ /LODGW86GNKBp9FeTxt9ag++zGvEEv8fi1YRvj08KaF4u7xzmZ8rhPl4xBXClPweYoBK cVfXXqFPJFVhppaPcn+NB3a4ZbN6MDFQAQVSnmdA5Ilh/f3TTwfwFOkVhSGOFzRiBzkw nqenhiCG/mVywKsGVUdaTwK35IDndptBH04oINeCqDrBrCql3P9Z/wNUUudbi6JDWyug BggQ== X-Gm-Message-State: ALoCoQkBrUpXPQeJvBAC7KjOJElLIFphsBTlpw26yFarTIfeWv7IGbTpsSkjEPe6BO2wwcICKccCiNah/s7dG2IGRG1QWI/YbQlW4JHJZEMpidcW+PenHP/zDxyOCBVU7fO/puo1XAFq X-Received: by 10.107.39.80 with SMTP id n77mr28440258ion.12.1427126855669; Mon, 23 Mar 2015 09:07:35 -0700 (PDT) X-Received: by 10.107.39.80 with SMTP id n77mr28440247ion.12.1427126855580; Mon, 23 Mar 2015 09:07:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Mon, 23 Mar 2015 09:07:05 -0700 (PDT) From: Brian Campbell Date: Mon, 23 Mar 2015 11:07:05 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a11407b6a46d5ad0511f6dda3 Archived-At: Subject: [OAUTH-WG] confirmation model in proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:07:41 -0000 --001a11407b6a46d5ad0511f6dda3 Content-Type: text/plain; charset=UTF-8 This is mostly about section 3.4 but also the whole draft. If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation element, it should probably contain an array value rather than an object value. SAML allows not just for multiple methods of confirming but for multiple instances of the same method. IIRC, only one confirmation needs to be confirmable. I'm not sure the extra complexity is worth it though. I've rarely, if ever, seen SAML assertions that make use of it. If the intent is just to allow for different kinds of confirmation, couldn't the structure be pared down and simplified and just have individual claims for the different confirmation types? Like "cjwk" and "ckid" or similar that have the jwk or kid value respectively as the member value. --001a11407b6a46d5ad0511f6dda3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is mostly about section 3.4= but also the whole draft.

If "cnf" is intended= to analogous to the SAML 2.0 SubjectConfirmation element, it should probab= ly contain an array value rather than an object value. SAML allows not just= for multiple methods of confirming but for multiple instances of the same = method. IIRC, only one confirmation needs to be confirmable.

<= div>I'm not sure the extra complexity is worth it though. I've rare= ly, if ever, seen SAML assertions that make use of it.

If= the intent is just to allow for different kinds of confirmation, couldn= 9;t the structure be pared down and simplified and just have individual cla= ims for the different confirmation types? Like "cjwk" and "c= kid" or similar that have the jwk or kid value respectively as the mem= ber value.=C2=A0




--001a11407b6a46d5ad0511f6dda3-- From nobody Mon Mar 23 09:18:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8D91AC42F for ; Mon, 23 Mar 2015 09:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 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_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham 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 XOKv-I_AxlOY for ; Mon, 23 Mar 2015 09:18:07 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::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 A8C7A1AC3F2 for ; Mon, 23 Mar 2015 09:18:06 -0700 (PDT) Received: by weop45 with SMTP id p45so142067671weo.0 for ; Mon, 23 Mar 2015 09:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cX/v2c7XZJLfC1/WDYpvMQrevcSbjKTEUbosgdpLK/0=; b=Ia3kSeBuNTuvtzGgjoSMGEJJmv+BpNkV0VRlcoFxtN8XlerbOCQB/hCo/eAigwYX/7 oCkb/TTXP0D+XTYO53Z7AJHyOFY2uY+yGaQ4tG1tq7FWhcX9Xv1U6/AhQK14kmjqCUDZ xRN5vYhrSoubpwroDm8+RWP9G4tCA2ifMbRMLXfVJRz7n/eR6HoivNwXBP/6NE3mzIID dghNgm2ZOebQW3CNUpgXTSruXbHauxI/V2pZ7e9R0S7BMESSM5q5RGGZc5bw0kvj3Xgz YTtE9e5N5tFbjwYpOhCqWxj8AR/FS1RGz3mi6bYhd4knTq/7Q7AtBsemvmx15SuAd345 mhZw== X-Received: by 10.194.176.162 with SMTP id cj2mr120901081wjc.93.1427127485424; Mon, 23 Mar 2015 09:18:05 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:59c6:d960:ea4:3c2e? ([2001:67c:370:136:59c6:d960:ea4:3c2e]) by mx.google.com with ESMTPSA id md2sm11871294wic.19.2015.03.23.09.18.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 09:18:03 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-CDCCC735-4CBE-455E-AEE4-1645A8261922 Mime-Version: 1.0 (1.0) From: Nat Sakimura X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Mon, 23 Mar 2015 11:18:00 -0500 Content-Transfer-Encoding: 7bit Message-Id: <04AB6674-B10F-4F28-ABE2-9A84CF22C137@gmail.com> References: To: Brian Campbell Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] confirmation model in proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:18:08 -0000 --Apple-Mail-CDCCC735-4CBE-455E-AEE4-1645A8261922 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable +1 =3Dnat via iPhone 2015/03/23 11:07=1B$B!"=1B(BBrian Campbell =1B$= B$N%a%C%;!<%8=1B(B: > This is mostly about section 3.4 but also the whole draft. >=20 > If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation elem= ent, it should probably contain an array value rather than an object value. S= AML allows not just for multiple methods of confirming but for multiple inst= ances of the same method. IIRC, only one confirmation needs to be confirmabl= e. >=20 > I'm not sure the extra complexity is worth it though. I've rarely, if ever= , seen SAML assertions that make use of it. >=20 > If the intent is just to allow for different kinds of confirmation, couldn= 't the structure be pared down and simplified and just have individual claim= s for the different confirmation types? Like "cjwk" and "ckid" or similar th= at have the jwk or kid value respectively as the member value. =20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-CDCCC735-4CBE-455E-AEE4-1645A8261922 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

=3Dnat via iPhone
=
2015/03/23 11:07=E3=80=81Brian Campbell <bcampbell@pingidentity.com> =E3=81=AE=E3=83=A1=E3=83= =83=E3=82=BB=E3=83=BC=E3=82=B8:

=
This is mostly about section 3.4 b= ut also the whole draft.

If "cnf" is intended to analogous= to the SAML 2.0 SubjectConfirmation element, it should probably contain an a= rray value rather than an object value. SAML allows not just for multiple me= thods of confirming but for multiple instances of the same method. IIRC, onl= y one confirmation needs to be confirmable.

I'm not sure t= he extra complexity is worth it though. I've rarely, if ever, seen SAML asse= rtions that make use of it.

If the intent is just to allow= for different kinds of confirmation, couldn't the structure be pared down a= nd simplified and just have individual claims for the different confirmation= types? Like "cjwk" and "ckid" or similar that have the jwk or kid value res= pectively as the member value. 




____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-CDCCC735-4CBE-455E-AEE4-1645A8261922-- From nobody Mon Mar 23 09:41:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24AA1ACD62 for ; Mon, 23 Mar 2015 09:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 JPkvSmEcZJU5 for ; Mon, 23 Mar 2015 09:40:59 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A470B1ACD2B for ; Mon, 23 Mar 2015 09:40:59 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKVRBCG2d1suyK9KmMQqrnlF7H8zXOBq9p@postini.com; Mon, 23 Mar 2015 09:40:59 PDT Received: by igbud6 with SMTP id ud6so47643145igb.1 for ; Mon, 23 Mar 2015 09:40:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fbLmKunV0erMXYlwywEw0Be1fICpMTO2KpyHu1HhyXs=; b=AXi6mPZeh170tlEFJEPO3UTGo0ihmw3CO7DR0q4+TJamztnJfIW4Or1dw4U9JujIwX qnemwYfjB10RKw3PgIf9WBPxT111V42D5juqSFJ7BMXbOWcmqtSKlQVsLI8SqHO85LQl 75uDZ2TyxJRM3NdAsmCppofEt4VteDRbI7qmAolbsXk5k2SSIIHPnqC5qI9w1myzGyKI iGIUb5TK+5abbrx3b6slb8OEVdq/6qduWNW0YLqnJWuSCIfGZYrH2O+SNJedjGWwd+7s +AEwHN66EaCUEjZ76593FRl/GxUuUVP/gR/FYnNRdca7Ff11TyyBdfxOJh0z9ZVjwjwK AuMQ== X-Gm-Message-State: ALoCoQnTiPwQ3GRJenFPYowxgw8+rL4Wuh5VDKnOnqu6/kxuC/LBcoIEsurbXtbMwWEBDrAp1s2P18Z6k9YTBdkASr4RTF1cD3Clz+xlWOQhD6LH+2co+upmEEmGkfm02Df/Ex6nUjWd X-Received: by 10.50.176.196 with SMTP id ck4mr16039717igc.40.1427128858717; Mon, 23 Mar 2015 09:40:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.176.196 with SMTP id ck4mr16039666igc.40.1427128858351; Mon, 23 Mar 2015 09:40:58 -0700 (PDT) Received: by 10.64.7.193 with HTTP; Mon, 23 Mar 2015 09:40:58 -0700 (PDT) Received: by 10.64.7.193 with HTTP; Mon, 23 Mar 2015 09:40:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 11:40:58 -0500 Message-ID: From: Brian Campbell To: Derek Atkins Content-Type: multipart/alternative; boundary=089e0111b8faa6b8a80511f754a7 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Lunch (pre-)Meeting Monday X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:41:05 -0000 --089e0111b8faa6b8a80511f754a7 Content-Type: text/plain; charset=UTF-8 Looks like we are heading to the bbq grill at the hotel, if you're (Hannes) late and still want to join us. On Mar 22, 2015 6:10 PM, "Derek Atkins" wrote: > Hi, > > Hannes and I would like to have a lunch meeting before the OAUTH meeting > to chat about various ongoing WG activities. If you're available and > interested meet us at IETF Regstration at 11:30 and we'll find a place. > I expect we'll leave by 11:35 so please be prompt. > > -derek and hannes > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e0111b8faa6b8a80511f754a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Looks like we are heading to the bbq grill at the hotel, if = you're (Hannes) late and still want to join us.

On Mar 22, 2015 6:10 PM, "Derek Atkins"= ; <derek@ihtfp.com> wrote:
Hi,

Hannes and I would like to have a lunch meeting before the OAUTH meeting to chat about various ongoing WG activities.=C2=A0 If you're available = and
interested meet us at IETF Regstration at 11:30 and we'll find a place.=
I expect we'll leave by 11:35 so please be prompt.

-derek and hannes
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.c= om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--089e0111b8faa6b8a80511f754a7-- From nobody Mon Mar 23 10:36:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035961ACEBD for ; Mon, 23 Mar 2015 10:36:38 -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, SPF_PASS=-0.001] autolearn=ham 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 JCeyQdoSttm3 for ; Mon, 23 Mar 2015 10:36:31 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::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 A234D1ACEC8 for ; Mon, 23 Mar 2015 10:36:31 -0700 (PDT) Received: by igbud6 with SMTP id ud6so49199533igb.1 for ; Mon, 23 Mar 2015 10:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=tGZ8r7ZgXQwcqOfJzrZLLEhYr+0fsaAs564kMtZ5AeU=; b=uKiECsrLvTbQxZ7u8bA58Z7wWfE1+vy6rb7moxbXtATT4JDRjD5CzjoIArr/MnJDo6 9WcrIpaw66xdRBCFSZf+/XviqJDSfdbUYmkGw+Ny8h/3Uq+mP+D8EiBWT04NiqlUMu3v C5wAVVpLiyEuUJDtbhj0mbkk41FIuBMHEGD43jRHuRhORU7ms5EFLtuC43WneM+twhlO fSThoBDLcxAThnAzlbTUPd9EqUAAjaeiInxvu7Gkvb9zQPt6Y13gf8yGgyxH6RKxaY4g sawdSpNpF5EtAQt8Us5USlLsH9EsPXnWkl3LTkcuGHv84/wLwat0Kkn9fkv1g2ddidz0 MRrg== X-Received: by 10.50.254.4 with SMTP id ae4mr16118261igd.10.1427132190976; Mon, 23 Mar 2015 10:36:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.252.8 with HTTP; Mon, 23 Mar 2015 10:36:10 -0700 (PDT) From: Adam Renberg Date: Mon, 23 Mar 2015 18:36:10 +0100 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11343b924a736b0511f81b52 Archived-At: Subject: [OAUTH-WG] Why are fragment components forbidden in the redirect_uri? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:36:38 -0000 --001a11343b924a736b0511f81b52 Content-Type: text/plain; charset=UTF-8 Section 3.1.2. of RFC6794 [0] says that: The redirection endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3. The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component. What is the reasoning behind this? Would there be security implications other than for query parameters if this was enabled? Or is it related to issues with 3xx redirects and fragments [1]? My google-foo fails me when I search through the archives. Could you please advice? Best regards, Adam Renberg [0]: https://tools.ietf.org/html/rfc6749#section-3.1.2 [1]: http://stackoverflow.com/questions/2286402/url-fragment-and-302-redirects --001a11343b924a736b0511f81b52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Section 3.1.2. of RFC6794 [0] says that:

The redirection endpoint URI MUST be an absolute URI as defined by
[RFC3986] Section 4.3.=C2=A0 The endpoint URI MAY include an
=
"application/x-www-form-urlencoded" formatted (per Appendix = B) query
component ([RFC3986] Section 3.4), which MUST be retaine= d when adding
additional query parameters.=C2=A0 The endpoint URI= MUST NOT include a
fragment component.

= What is the reasoning behind this? Would there be security implications oth= er than for query parameters if this was enabled? Or is it related to issue= s with 3xx redirects and fragments [1]?

My google-= foo fails me when I search through the archives. Could you please advice?

--001a11343b924a736b0511f81b52-- From nobody Mon Mar 23 10:56:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6951AD09D for ; Mon, 23 Mar 2015 10:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 j45LH7EYqnPb for ; Mon, 23 Mar 2015 10:56:31 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE9B1AD065 for ; Mon, 23 Mar 2015 10:56:31 -0700 (PDT) Received: from mail-ie0-f171.google.com ([209.85.223.171]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKVRBTzqrT50XIBUD77Sp+O/OJolHrYOzB@postini.com; Mon, 23 Mar 2015 10:56:31 PDT Received: by ieclw3 with SMTP id lw3so42028468iec.2 for ; Mon, 23 Mar 2015 10:56:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7kx8ZoFSjZpxKAa7XHDvNg6oeuaeGyqnjGpyr7Fj+s4=; b=Y02gQ7y63RQc4xeHk9MYOPhksZF0qUEePLHcjJ4F6am9S9102nLCdmIjvUN9kygpbN 5p6qP3+GPSfg/C0dEfWVpTDvmdAvlb5M7LTCEKElJr2kvojTj7yCJuWb90BpRvOb6eAI qE/yjVvMd5KlHYEFnL1hxtKG99D+hvzlu/uINErNa1mPM5a72L/R4T0dr6NABKy6zonE yzK5tv4iN7fspG0S4LL7GAWayotXzrOqzUhmMP37oRjjMFBdeRTTAUuOAbIHzujEjjeW +U0ed1YvcQxYhCm1L4oYAafjM09ymOW9eUusz3nqENTsm2izi/Lp0qErkxwMvOEk1jkJ EMGw== X-Gm-Message-State: ALoCoQmdchBVcDXYEMHTThcpk8LH17PbB0oso5lByyDH3F3xxFUr9c7vWC1WTM6Jp8OFCLb9S2cZNLRKQ7jiEPgN+3SafS8e83GOyLyyUDZEELSEz3DoK80ZKIc2Dqfbgg/VaU9fuFtM X-Received: by 10.107.156.19 with SMTP id f19mr498359ioe.45.1427133390085; Mon, 23 Mar 2015 10:56:30 -0700 (PDT) X-Received: by 10.107.156.19 with SMTP id f19mr498348ioe.45.1427133390005; Mon, 23 Mar 2015 10:56:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Mon, 23 Mar 2015 10:55:59 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 23 Mar 2015 12:55:59 -0500 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a1141b9acc240cb0511f862c9 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:56:36 -0000 --001a1141b9acc240cb0511f862c9 Content-Type: text/plain; charset=UTF-8 Yeah, it could be done with kid. But that would require a bit more out-of-band understanding between the parties to know that the kid is, in fact, a thumbprint. Seems like it'd be better to outright support a thumbprint rather than overloading kid, if thumbprint representation of the key for confirmation is desirable. And yes, a thumbprint does have some nice properties. But I am also very sympathetic to the "too many ways is not good for interop" point. That's kind of why I asked what others thought of it rather than just making a suggestion. I'm not sure one way or the other myself. On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura wrote: > Would not kid do? > Right, thumbprint has more semantics and has nice properties, but having > too many ways is not good for interop. > > Nat > > 2015-03-23 15:40 GMT+09:00 Brian Campbell : > >> Do folks in the WG think there'd be utility in having a way to identity >> the finger/thumbprint of a key in the cnf claim. A presenter might, for >> example, present the JWT along with a public JWK and some >> proof-of-possession of that JWK. And the JWK would be bound to the JWT via >> the thumbprint, which is more space efficient (with respect to the JWT >> anyway) than the full JWK. >> >> >> >> _______________________________________________ >> 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 > --001a1141b9acc240cb0511f862c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, it could be done with kid. But that would requi= re a bit more out-of-band understanding between the parties to know that th= e kid is, in fact, a thumbprint. Seems like it'd be better to outright = support a thumbprint rather than overloading kid, if thumbprint representat= ion of the key for confirmation is desirable.

And yes, a thum= bprint does have some nice properties. But I am also very sympathetic to th= e "too many ways is not good for interop" point. That's kind = of why I asked what others thought of it rather than just making a suggesti= on. I'm not sure one way or the other myself.

On Mon, Mar 23, 2015 at 2:11 AM, = Nat Sakimura <sakimura@gmail.com> wrote:
Would not kid do?=C2=A0
Rig= ht, thumbprint has more semantics and has nice properties, but having too m= any ways is not good for interop.=C2=A0

Nat
<= /div>

2015-03-23 15:40 GMT+09:00 Brian Campbell <bcampbell@pingid= entity.com>:
Do folks in the WG think there'd be utility = in having a way to identity the finger/thumbprint of a key in the cnf claim= . A presenter might, for example, present the JWT along with a public JWK a= nd some proof-of-possession of that JWK.=C2=A0 And the JWK would be bound t= o the JWT via the thumbprint, which is more space efficient (with respect t= o the JWT anyway) than the full JWK.



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


<= br clear=3D"all">

--
Nat Sakimura (=3Dnat)
Chair= man, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--001a1141b9acc240cb0511f862c9-- From nobody Mon Mar 23 11:01:05 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796131AD09B for ; Mon, 23 Mar 2015 11:01: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, SPF_PASS=-0.001] autolearn=ham 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 Kxe3H_bQxgI8 for ; Mon, 23 Mar 2015 11:01:02 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003: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 990A01AD0AA for ; Mon, 23 Mar 2015 11:00:46 -0700 (PDT) Received: by oifl3 with SMTP id l3so117415408oif.0 for ; Mon, 23 Mar 2015 11:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=M606ctHR1LSg3nrIAhOjy7otymFMdL9W618RKsF4t4w=; b=NSeNs0Jh8PBqAliNF6Aoem6+HTSlpz/FlBqpiaSt7YOn+2lC+qEzOOUa0HAJWrAOwd oXZjulxOi2g+N1+FMYfAwS9LGqt7v++srfSqbzoxwwrBIeysmp92EjFJv2kSm5snz9Xy K0EBQx3GlymQzJ6ZHrU6J7cJGgfZy6RpYBnsPKcBhDjHkJVRNFzJ/my6yURAPIdNIXDb c9IJhaq53OgdbT/u8nC5rPMMmUjVPj9nAHLk+vtO4aQEHFxWlvaBDnD181WN2BXD8gGQ r+55np6zoMMFb4A/ht6uUB4f7TTfY90797/URDIZal+RmsIv9o/lQj6DVwYCxKfOezjk eXBA== X-Received: by 10.202.180.87 with SMTP id d84mr358789oif.0.1427133645982; Mon, 23 Mar 2015 11:00:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Mon, 23 Mar 2015 18:00:44 +0000 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113cc7e00414210511f87295 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:01:04 -0000 --001a113cc7e00414210511f87295 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for dropping kid in favor of thumbprint. 2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 12:56 Brian Campbell : > Yeah, it could be done with kid. But that would require a bit more > out-of-band understanding between the parties to know that the kid is, in > fact, a thumbprint. Seems like it'd be better to outright support a > thumbprint rather than overloading kid, if thumbprint representation of t= he > key for confirmation is desirable. > > And yes, a thumbprint does have some nice properties. But I am also very > sympathetic to the "too many ways is not good for interop" point. That's > kind of why I asked what others thought of it rather than just making a > suggestion. I'm not sure one way or the other myself. > > On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura wrote: > >> Would not kid do? >> Right, thumbprint has more semantics and has nice properties, but having >> too many ways is not good for interop. >> >> Nat >> >> 2015-03-23 15:40 GMT+09:00 Brian Campbell : >> >>> Do folks in the WG think there'd be utility in having a way to identity >>> the finger/thumbprint of a key in the cnf claim. A presenter might, for >>> example, present the JWT along with a public JWK and some >>> proof-of-possession of that JWK. And the JWK would be bound to the JWT= via >>> the thumbprint, which is more space efficient (with respect to the JWT >>> anyway) than the full JWK. >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > --001a113cc7e00414210511f87295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for dropping kid in favor of thumbprint.
= 2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 12:56 Brian Campbell <bcampbell@pingidentity.com>= ;:
Yeah, it could b= e done with kid. But that would require a bit more out-of-band understandin= g between the parties to know that the kid is, in fact, a thumbprint. Seems= like it'd be better to outright support a thumbprint rather than overl= oading kid, if thumbprint representation of the key for confirmation is des= irable.

And yes, a thumbprint does have some nice properties.= But I am also very sympathetic to the "too many ways is not good for = interop" point. That's kind of why I asked what others thought of = it rather than just making a suggestion. I'm not sure one way or the ot= her myself.

On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura <sakimura@gmail.com= > wrote:
= Would not kid do?=C2=A0
Right, thumbprint has more semantics and = has nice properties, but having too many ways is not good for interop.=C2= =A0

Nat

=
2015-03-23 15:40 GMT+09:00 Brian Campbell = <bcampbell@pingidentity.com>:
Do folks in the WG think there&= #39;d be utility in having a way to identity the finger/thumbprint of a key= in the cnf claim. A presenter might, for example, present the JWT along wi= th a public JWK and some proof-of-possession of that JWK.=C2=A0 And the JWK= would be bound to the JWT via the thumbprint, which is more space efficien= t (with respect to the JWT anyway) than the full JWK.



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



=

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en

--001a113cc7e00414210511f87295-- From nobody Mon Mar 23 11:42:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D5C1AD0CE; Mon, 23 Mar 2015 11:42:30 -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] autolearn=ham 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 NF-z_HllLOS7; Mon, 23 Mar 2015 11:42:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DEF1AD244; Mon, 23 Mar 2015 11:42:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323184226.15271.92342.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 11:42:26 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:42:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-11.txt Pages : 18 Date : 2015-03-23 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-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 Mon Mar 23 11:47:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EF21AD23D for ; Mon, 23 Mar 2015 11:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 paZwpWJ-jxat for ; Mon, 23 Mar 2015 11:47:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134291AD0C3 for ; Mon, 23 Mar 2015 11:47:47 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.125.14; Mon, 23 Mar 2015 18:47:47 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Mon, 23 Mar 2015 18:47:46 +0000 From: Mike Jones To: Nat Sakimura , Brian Campbell Thread-Topic: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? Thread-Index: AQHQZTRfYlKVul2ynECUxNG74nzcQJ0pprQAgAC0H4CAAAFUAIAADSX/ Date: Mon, 23 Mar 2015 18:47:46 +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: [166.173.61.82] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377424004)(24454002)(377454003)(15975445007)(46102003)(33656002)(102836002)(106116001)(40100003)(76176999)(54356999)(74316001)(77096005)(76576001)(122556002)(230783001)(93886004)(16236675004)(77156002)(62966003)(66066001)(99286002)(86612001)(86362001)(2950100001)(2900100001)(19580395003)(19580405001)(19617315012)(50986999)(87936001)(92566002)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 05245CA661 Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4425191C39617F71B40C263F50D0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2015 18:47:46.5770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:47:50 -0000 --_000_BY2PR03MB4425191C39617F71B40C263F50D0BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable In JWT, we generally use key IDs to identify keys. Per draft-ietf-jose-jwt= -thumbprint, *one* value that can be used as a key ID, but it's not the onl= y one. That's up to the application. But especially since Jim Schaad had us take out the thumbprint claim names,= "kid" is the clear winner as the claim name. Let's keep it. -- Mike ________________________________ From: Nat Sakimura Sent: =FD3/=FD23/=FD2015 1:01 PM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? +1 for dropping kid in favor of thumbprint. 2015?3?23?(?) 12:56 Brian Campbell >: Yeah, it could be done with kid. But that would require a bit more out-of-b= and understanding between the parties to know that the kid is, in fact, a t= humbprint. Seems like it'd be better to outright support a thumbprint rathe= r than overloading kid, if thumbprint representation of the key for confirm= ation is desirable. And yes, a thumbprint does have some nice properties. But I am also very sy= mpathetic to the "too many ways is not good for interop" point. That's kind= of why I asked what others thought of it rather than just making a suggest= ion. I'm not sure one way or the other myself. On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura > wrote: Would not kid do? Right, thumbprint has more semantics and has nice properties, but having to= o many ways is not good for interop. Nat 2015-03-23 15:40 GMT+09:00 Brian Campbell >: Do folks in the WG think there'd be utility in having a way to identity the= finger/thumbprint of a key in the cnf claim. A presenter might, for exampl= e, present the JWT along with a public JWK and some proof-of-possession of = that JWK. And the JWK would be bound to the JWT via the thumbprint, which = is more space efficient (with respect to the JWT anyway) than the full JWK. _______________________________________________ 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 --_000_BY2PR03MB4425191C39617F71B40C263F50D0BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
In JWT, we ge= nerally use key IDs to identify keys.  Per draft-ietf-jose-jwt-thumbpr= int, *one* value that can be used as a key ID, but it's not the only one. T= hat's up to the application.

But especially since Jim Schaad had us take out the thumbprint claim names,= "kid" is the clear winner as the claim name.  Let's keep it= .

-- Mike
From: Nat Sakimura
Sent: =FD3/= =FD23/=FD2015 1:01 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [= OAUTH-WG] proof-of-possession-02 cnf via key thumbprint?

+1 for dropping kid in favor of thumbprint.
2015年3月23日(月) 12:56 = Brian Campbell <bcampbell@= pingidentity.com>:
Yeah, it could be done with kid. But that would require a bit more out= -of-band understanding between the parties to know that the kid is, in fact= , a thumbprint. Seems like it'd be better to outright support a thumbprint = rather than overloading kid, if thumbprint representation of the key for confirmation is desirable.

And yes, a thumbprint does have some nice properties. But I am also very sy= mpathetic to the "too many ways is not good for interop" point. T= hat's kind of why I asked what others thought of it rather than just making= a suggestion. I'm not sure one way or the other myself.

On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura <sakimura@gmail.= com> wrote:
Would not kid do? 
Right, thumbprint has more semantics and has nice properties, but havi= ng too many ways is not good for interop. 

Nat

2015-03-23 15:40 GMT+09:00 Brian Campb= ell <bcampbe= ll@pingidentity.com>:
Do folks in the WG think there'd be utility in having a wa= y to identity the finger/thumbprint of a key in the cnf claim. A presenter = might, for example, present the JWT along with a public JWK and some proof-= of-possession of that JWK.  And the JWK would be bound to the JWT via the thumbprint, which is more space effi= cient (with respect to the JWT anyway) than the full JWK.



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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

--_000_BY2PR03MB4425191C39617F71B40C263F50D0BY2PR03MB442namprd_-- From nobody Mon Mar 23 11:51:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A831C1AD34C for ; Mon, 23 Mar 2015 11:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4bJUK2JJX156 for ; Mon, 23 Mar 2015 11:51:36 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C6D1AD0CE for ; Mon, 23 Mar 2015 11:51:35 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-07-551060b656a9 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.86.03678.6B060155; Mon, 23 Mar 2015 14:51:34 -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 t2NIpXMY029475; Mon, 23 Mar 2015 14:51:33 -0400 Received: from dhcp-b0dd.meeting.ietf.org (dhcp-b0dd.meeting.ietf.org [31.133.176.221]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2NIpUnp013229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Mar 2015 14:51:32 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A3ADEBA6-491F-4715-9F72-ED0D500806CC"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: Date: Mon, 23 Mar 2015 13:51:30 -0500 Message-Id: <6E85F10B-89D3-4B17-BFB0-86F2F085E965@mit.edu> References: <, > To: Mike Jones X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFKsWRmVeSWpSXmKPExsUixG6nrrstQSDUYOs5SYvV/28yWuyd9onF 4uTbV2wWZ26tYHRg8dg56y67x5IlP5k8Wnf8Zfe4e/QiSwBLFJdNSmpOZllqkb5dAlfG+f4+ 1oKjkRVrrzWxNjBe8e1i5OSQEDCROHl9CiuELSZx4d56ti5GLg4hgcVMEgsXfmeHcDYySnzd NoMdpEpI4AqTxMkPYSC2sICbROOefjYQm1fAQGLuqS9MIA3MAlMYJXY9fAY1Vkqi6fUxRhCb TUBVYvqaFiYQm1MgWuLYzllgQ1mA4p8XrmCEaO5klJg4byszxFQriZmNC6Bu+sQkseV1C9hU EQEdiccXvwElOIA2yEv0bEqfwCg4C8khs5AdMguojFkgSeLB1UyQGmYBbYllC18zQ9iaEvu7 l7NgimtIdH6byAphy0tsfzsHKm4psXjmDah6W4lbfQuYIGw7iUfTFrEuYORexSibklulm5uY mVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERytLqo7GCccUjrEKMDBqMTDWxHAHyrEmlhWXJl7 iFGSg0lJlDcpSiBUiC8pP6UyI7E4I76oNCe1+BCjCtCuRxtWX2CUYsnLz0tVEuGNdQGq401J rKxKLcqHKZPmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwbskHqhRsCg1PbUiLTOnBCHN xMF5iFGCgwdoeB9IDW9xQWJucWY6RP4Uo6KUOG8KSEIAJJFRmgfXC0uyrxjFgd4S5n0AUsUD TNBw3a+ABjMBDT6XzwcyuCQRISXVwNgaqvUnY88anzzrxTmHNogzOv6bqHeSe+/zxey7rtYI sfHe0vvOunrqNcGbBq0nlgoZXgkqTFK5ccxBwFfnzfolfO/3/GI6e09a+I/CC93T+7KzZKMe fJdhFhQTyD+Res4jPEro11TXgk9GGidE5mq+971S+KxD5/6/zeuaFkjw8rVNrAz5zKfEUpyR aKjFXFScCAAwzcTgjQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:51:38 -0000 --Apple-Mail=_A3ADEBA6-491F-4715-9F72-ED0D500806CC Content-Type: multipart/alternative; boundary="Apple-Mail=_9C563821-439C-4918-A58D-F7C980FAAD39" --Apple-Mail=_9C563821-439C-4918-A58D-F7C980FAAD39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 The thumbprint is a semantic way to identify a key. The key id claim = name is the syntactic representation of a key identifier of any type. = One type of key ID is a thumbprint. One place to put a thumbprint is in = a key ID. =E2=80=94 Justin > On Mar 23, 2015, at 1:47 PM, Mike Jones = wrote: >=20 > In JWT, we generally use key IDs to identify keys. Per = draft-ietf-jose-jwt-thumbprint, *one* value that can be used as a key = ID, but it's not the only one. That's up to the application. >=20 > But especially since Jim Schaad had us take out the thumbprint claim = names, "kid" is the clear winner as the claim name. Let's keep it. >=20 > -- Mike > From: Nat Sakimura > Sent: =E2=80=8E3/=E2=80=8E23/=E2=80=8E2015 1:01 PM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? >=20 > +1 for dropping kid in favor of thumbprint. > 2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 12:56 Brian Campbell = >: > Yeah, it could be done with kid. But that would require a bit more = out-of-band understanding between the parties to know that the kid is, = in fact, a thumbprint. Seems like it'd be better to outright support a = thumbprint rather than overloading kid, if thumbprint representation of = the key for confirmation is desirable. >=20 > And yes, a thumbprint does have some nice properties. But I am also = very sympathetic to the "too many ways is not good for interop" point. = That's kind of why I asked what others thought of it rather than just = making a suggestion. I'm not sure one way or the other myself. >=20 > On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura > wrote: > Would not kid do? > Right, thumbprint has more semantics and has nice properties, but = having too many ways is not good for interop. >=20 > Nat >=20 > 2015-03-23 15:40 GMT+09:00 Brian Campbell >: > Do folks in the WG think there'd be utility in having a way to = identity the finger/thumbprint of a key in the cnf claim. A presenter = might, for example, present the JWT along with a public JWK and some = proof-of-possession of that JWK. And the JWK would be bound to the JWT = via the thumbprint, which is more space efficient (with respect to the = JWT anyway) than the full JWK. >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9C563821-439C-4918-A58D-F7C980FAAD39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

The = thumbprint is a semantic way to identify a key. The key id claim name is = the syntactic representation of a key identifier of any type. One type = of key ID is a thumbprint. One place to put a thumbprint is in a key = ID. 

 =E2=80=94 Justin

On = Mar 23, 2015, at 1:47 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

In JWT, we generally use key IDs to identify keys.  Per = draft-ietf-jose-jwt-thumbprint, *one* value that can be used as a key = ID, but it's not the only one. That's up to the application.

But especially since Jim Schaad had us take out the thumbprint claim = names, "kid" is the clear winner as the claim name.  Let's keep = it.

-- Mike
From: Nat = Sakimura
Sent: =E2=80=8E3/=E2=80=8E23/=E2=80=8E2015 1:01 PM
To: Brian = Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key = thumbprint?

+1 for dropping kid in favor of thumbprint.
2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) = 12:56 Brian Campbell <bcampbell@pingidentity.com>:
Yeah, it could be done with kid. But that would require = a bit more out-of-band understanding between the parties to know that = the kid is, in fact, a thumbprint. Seems like it'd be better to outright = support a thumbprint rather than overloading kid, if thumbprint representation of the key for confirmation is desirable.

And yes, a thumbprint does have some nice properties. But I am also very = sympathetic to the "too many ways is not good for interop" point. That's = kind of why I asked what others thought of it rather than just making a = suggestion. I'm not sure one way or the other myself.

On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura = <sakimura@gmail.com> wrote:
Would not kid do? 
Right, thumbprint has more semantics and has nice = properties, but having too many ways is not good for = interop. 

Nat

2015-03-23 15:40 GMT+09:00 = Brian Campbell <bcampbell@pingidentity.com>:
Do folks in the WG think there'd be utility = in having a way to identity the finger/thumbprint of a key in the cnf = claim. A presenter might, for example, present the JWT along with a = public JWK and some proof-of-possession of that JWK.  And the JWK would be bound to the JWT via the thumbprint, which is more space = efficient (with respect to the JWT anyway) than the full JWK.



_______________________________________________
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

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

= --Apple-Mail=_9C563821-439C-4918-A58D-F7C980FAAD39-- --Apple-Mail=_A3ADEBA6-491F-4715-9F72-ED0D500806CC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVEGCyAAoJEDPAngkbd+w9tzAH/iyhk8CCtGOA4L5hQztvd3Z0 UWe0eum8UCXWzQigfABCeH3n3FzLBvxMMfgs4G65bQ6o3STk/LYZ1+hNShVvaqgW T+xvK17fXmxqf9pZNzy0dIV2f7wlcuReSo0BsZRTxD4Ca1g51CuuMC6AofboOYNF UcGIi+MMQ0gJDdfqclPtt4L7/0CZN9SulfyUusowXEOzdlyBbqlJsRrUxj96cQ3f 9EgIdGIp6bcgkTx10A0HGOzaTRNY+O7Gk5psAgWXORhcxWwng9mhIlIrB0v0nRo9 YIxeFDqkQDorv5SAM6R8DD3LlfdmyKjvaGteCLtIyaK/ngKFWlSQoKmk6lGHbTw= =gc3G -----END PGP SIGNATURE----- --Apple-Mail=_A3ADEBA6-491F-4715-9F72-ED0D500806CC-- From nobody Mon Mar 23 11:52:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241101AD355 for ; Mon, 23 Mar 2015 11:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 OXnzQjvyc7ZZ for ; Mon, 23 Mar 2015 11:52:27 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC0F1AD34F for ; Mon, 23 Mar 2015 11:52:27 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKVRBg64auxTLGHx55ou0M1OvXol+IP1tN@postini.com; Mon, 23 Mar 2015 11:52:27 PDT Received: by igbqf9 with SMTP id qf9so47101082igb.1 for ; Mon, 23 Mar 2015 11:52:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tWaQDcsq98wRUhgmMetWbIgANlJ38u9HMPP0rGRMhKk=; b=LhHvzt/CSUJy8rk4khR1N3VOlq9Oz9GRYfQqM5vcb7aLogWy94HOsKMCs1T5nLuKb7 tBm801eWb3qdnZc33ZLm+RrRdrcO99rd8rIhJVvnLz0IIIMqh46R3zXJQqcbeItbV38S os24BKb8xAWS5M2fYQcGvz42LN9tWvEDpvR6WwQ1PIf/tFoTnK4pQWSzQKp1OAHzrlI8 e1ZeXo6TTV9vgpX6UKXE2xKR1nYrw3PPP3j7Mqdv+rrtnhD7Xtq5t8vY3NYen4qTSjUQ BgCmlxCyg/JX+zx8UJKamk23Hu5pLZ0EBK/ys4IrjkLUN7iVt/Tv40tLcy6B0dLwdzeE kQ3A== X-Gm-Message-State: ALoCoQn6CygggYCkchg3ZPblC8ApTsTanFtWC7Xxgz2NXnwjQYAIwqMYkehwUcQapUN/7b8Log+KjeqrHj5ftaPiMFNcWuHHBHfv8u1vtCa4M81i3xEqS5FhBUGc5u0scYHlzl8SQMTx X-Received: by 10.43.142.5 with SMTP id jg5mr10160170icc.33.1427136747036; Mon, 23 Mar 2015 11:52:27 -0700 (PDT) X-Received: by 10.43.142.5 with SMTP id jg5mr10160158icc.33.1427136746954; Mon, 23 Mar 2015 11:52:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Mon, 23 Mar 2015 11:51:56 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 23 Mar 2015 13:51:56 -0500 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a11c2da1ad936de0511f92a14 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:52:32 -0000 --001a11c2da1ad936de0511f92a14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I wasn't necessarily suggesting to drop the kid one. On Mon, Mar 23, 2015 at 1:00 PM, Nat Sakimura wrote: > +1 for dropping kid in favor of thumbprint. > 2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 12:56 Brian Campbell : > > Yeah, it could be done with kid. But that would require a bit more >> out-of-band understanding between the parties to know that the kid is, i= n >> fact, a thumbprint. Seems like it'd be better to outright support a >> thumbprint rather than overloading kid, if thumbprint representation of = the >> key for confirmation is desirable. >> >> And yes, a thumbprint does have some nice properties. But I am also very >> sympathetic to the "too many ways is not good for interop" point. That's >> kind of why I asked what others thought of it rather than just making a >> suggestion. I'm not sure one way or the other myself. >> >> On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura wrote= : >> >>> Would not kid do? >>> Right, thumbprint has more semantics and has nice properties, but havin= g >>> too many ways is not good for interop. >>> >>> Nat >>> >>> 2015-03-23 15:40 GMT+09:00 Brian Campbell : >>> >>>> Do folks in the WG think there'd be utility in having a way to identit= y >>>> the finger/thumbprint of a key in the cnf claim. A presenter might, fo= r >>>> example, present the JWT along with a public JWK and some >>>> proof-of-possession of that JWK. And the JWK would be bound to the JW= T via >>>> the thumbprint, which is more space efficient (with respect to the JWT >>>> anyway) than the full JWK. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> --001a11c2da1ad936de0511f92a14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wasn't necessarily suggesting to drop the kid one.

On Mon, M= ar 23, 2015 at 1:00 PM, Nat Sakimura <sakimura@gmail.com> w= rote:
+1 for dropping kid in favor of thu= mbprint.
2015=E5=B9=B43=E6=9C=8823=E6=97=A5(= =E6=9C=88) 12:56 Brian Campbell <bcampbell@pingidentity.com>:

Yeah, it c= ould be done with kid. But that would require a bit more out-of-band unders= tanding between the parties to know that the kid is, in fact, a thumbprint.= Seems like it'd be better to outright support a thumbprint rather than= overloading kid, if thumbprint representation of the key for confirmation = is desirable.

And yes, a thumbprint does have some nice prope= rties. But I am also very sympathetic to the "too many ways is not goo= d for interop" point. That's kind of why I asked what others thoug= ht of it rather than just making a suggestion. I'm not sure one way or = the other myself.

On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura &= lt;sakimura@gmail.c= om> wrote:
Would not kid do?=C2=A0
Right, thumbprint has more semantic= s and has nice properties, but having too many ways is not good for interop= .=C2=A0

Nat
=
2015-03-23 15:40 GMT+09:00 Brian Campb= ell <bcampbell@pingidentity.com>:
Do folks in the WG think the= re'd be utility in having a way to identity the finger/thumbprint of a = key in the cnf claim. A presenter might, for example, present the JWT along= with a public JWK and some proof-of-possession of that JWK.=C2=A0 And the = JWK would be bound to the JWT via the thumbprint, which is more space effic= ient (with respect to the JWT anyway) than the full JWK.



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



=

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en


--001a11c2da1ad936de0511f92a14-- From nobody Mon Mar 23 11:55:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591D61AD35B for ; Mon, 23 Mar 2015 11:55: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, SPF_PASS=-0.001] autolearn=ham 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 ikJ5FP9lGIdl for ; Mon, 23 Mar 2015 11:55:21 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003: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 DDB811AD357 for ; Mon, 23 Mar 2015 11:55:13 -0700 (PDT) Received: by oifl3 with SMTP id l3so118754139oif.0 for ; Mon, 23 Mar 2015 11:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=pmmJTFbvGfl/RcEoFdtH+oS4GmEVAyrUKW3fdMu6eyk=; b=MZt8zQau0qa5AjH/73i0qEEJEb91KbPxKj0WaD12CWEt4MU/77L0ouYYePMSKZKf/e vPdyuuPV/UtQx4fFi+Lixs5PiFmQXpoHfFW4su9gjTHAR4vt/BovLch81NhAjyOASzw3 S9jL1LWxTI/PHpZNxwf4L+NAemnQt1FQs4Jc6h/lO0TzPSHoo2dOuKbQDIy5ysDH5lFD xqA2Hws/tzRwn8vChaPmy21/4YR7or69OmX7M+MJQhFel7YbV0tESvTNRIcHU7+XQTVI cwq2f+iw3EFbzxFzBrrDSA5d/qeyAm9MmobaHiRtM9QnIJ3LN8Yfqtfa+jHgSjR+Nx8O obWA== X-Received: by 10.202.63.132 with SMTP id m126mr361681oia.33.1427136913345; Mon, 23 Mar 2015 11:55:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Mon, 23 Mar 2015 18:55:11 +0000 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113d660ac416880511f934b0 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:55:23 -0000 --001a113d660ac416880511f934b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ok, this is a full circle to my original comment "Would not kid do? " 2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 13:52 Brian Campbell : > I wasn't necessarily suggesting to drop the kid one. > > On Mon, Mar 23, 2015 at 1:00 PM, Nat Sakimura wrote: > >> +1 for dropping kid in favor of thumbprint. >> 2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 12:56 Brian Campbell : >> >> Yeah, it could be done with kid. But that would require a bit more >>> out-of-band understanding between the parties to know that the kid is, = in >>> fact, a thumbprint. Seems like it'd be better to outright support a >>> thumbprint rather than overloading kid, if thumbprint representation of= the >>> key for confirmation is desirable. >>> >>> And yes, a thumbprint does have some nice properties. But I am also ver= y >>> sympathetic to the "too many ways is not good for interop" point. That'= s >>> kind of why I asked what others thought of it rather than just making a >>> suggestion. I'm not sure one way or the other myself. >>> >>> On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura >>> wrote: >>> >>>> Would not kid do? >>>> Right, thumbprint has more semantics and has nice properties, but >>>> having too many ways is not good for interop. >>>> >>>> Nat >>>> >>>> 2015-03-23 15:40 GMT+09:00 Brian Campbell = : >>>> >>>>> Do folks in the WG think there'd be utility in having a way to >>>>> identity the finger/thumbprint of a key in the cnf claim. A presenter >>>>> might, for example, present the JWT along with a public JWK and some >>>>> proof-of-possession of that JWK. And the JWK would be bound to the J= WT via >>>>> the thumbprint, which is more space efficient (with respect to the JW= T >>>>> anyway) than the full JWK. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> > --001a113d660ac416880511f934b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ok, this is a full circle to my original comment "Would not kid do? &q= uot;
2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6= =9C=88) 13:52 Brian Campbell <bcampbell@pingidentity.com>:
<= div dir=3D"ltr">I wasn't necessarily suggesting to drop the kid one.

On Mon, Ma= r 23, 2015 at 1:00 PM, Nat Sakimura <sakimura@gmail.com> wr= ote:
+1 for dropping kid in favor of thum= bprint.
2015=E5=B9=B43=E6=9C=8823=E6=97=A5(= =E6=9C=88) 12:56 Brian Campbell <bcampbell@pingidentity.com>:

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Yeah, it could be done = with kid. But that would require a bit more out-of-band understanding betwe= en the parties to know that the kid is, in fact, a thumbprint. Seems like i= t'd be better to outright support a thumbprint rather than overloading = kid, if thumbprint representation of the key for confirmation is desirable.=

And yes, a thumbprint does have some nice properties. But I = am also very sympathetic to the "too many ways is not good for interop= " point. That's kind of why I asked what others thought of it rath= er than just making a suggestion. I'm not sure one way or the other mys= elf.

On = Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura <sakimura@gmail.com> wrote:
Would n= ot kid do?=C2=A0
Right, thumbprint has more semantics and has nic= e properties, but having too many ways is not good for interop.=C2=A0
=

Nat

2015-03-23 15:40 GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:
Do folks in the WG think there'd be u= tility in having a way to identity the finger/thumbprint of a key in the cn= f claim. A presenter might, for example, present the JWT along with a publi= c JWK and some proof-of-possession of that JWK.=C2=A0 And the JWK would be = bound to the JWT via the thumbprint, which is more space efficient (with re= spect to the JWT anyway) than the full JWK.



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



=

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en


--001a113d660ac416880511f934b0-- From nobody Mon Mar 23 12:40:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B691A01F6 for ; Mon, 23 Mar 2015 12:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 geKapxU8cysS for ; Mon, 23 Mar 2015 12:40:38 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321F41A0242 for ; Mon, 23 Mar 2015 12:40:37 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-27-55106c345242 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 71.01.03359.43C60155; Mon, 23 Mar 2015 15:40:37 -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 t2NJearF003708 for ; Mon, 23 Mar 2015 15:40:36 -0400 Received: from dhcp-b0dd.meeting.ietf.org (dhcp-b0dd.meeting.ietf.org [31.133.176.221]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2NJeYG7030215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Mar 2015 15:40:36 -0400 From: Justin Richer X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_6E45F2AF-E9F9-4412-BB88-988FDCA71F0D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Mon, 23 Mar 2015 14:40:33 -0500 Message-Id: <0C7C1508-DA58-4832-B755-F8BA1F153894@mit.edu> To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUixG6nrmuaIxBqsKOB2eLk21dsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmD/3D1tBO2fF39XbWBoYV3B0MXJySAiYSJzY+4YRwhaTuHBv PVsXIxeHkMBiJolFkxcxQzjHGCU+HvgN5bxkkrj8dwVYC5uAqsT8lbeYINqlJJpeH2MEKWIW mMIocWFNN1AHB4ewgJbE54vyIDUsQPU3Fl8Fq+cVsJKY3/wObI6IgLrEmvM/oeIGEnNPfWEC aZUQkJfo2ZQ+gZFvFrKps5CUgdjMAtoSyxa+ZoawNSX2dy9ngbDlJba/nQMVt5RYPPMGVNxW 4lbfAqheO4lH0xaxLmDkWMUom5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKXmlK6iREU3pyS PDsY3xxUOsQowMGoxMNbEcAfKsSaWFZcmXuIUZKDSUmUNylKIFSILyk/pTIjsTgjvqg0J7X4 EKMK0K5HG1ZfYJRiycvPS1US4Y11AarjTUmsrEotyocpk+ZgURLn3fSDL0RIID2xJDU7NbUg tQgmK8PBoSTB65oF1ChYlJqeWpGWmVOCkGbi4DzEKMHBAzT8USbI8OKCxNzizHSI/ClGRSlx 3iKQZgGQREZpHlwvLC29YhQHekuYdzNIFQ8wpcF1vwIazAQ0+Fw+H8jgkkSElFQD46KZsz3c p/pcC+5dsPRmTuPu+FPqF4qb+oLCnuev6er3aLAQjDU5Z6r25Miex4U7q98oM0doZRp/OHHp isYhOaaNyoYSL2ffuzX/pVrM47/bTALF9sew3Z9dOFVb4EvqlxsiGvPzk6T9PkgLxd1gu+zQ U/Vgj3Qjy+Ur1dPKQzfdLdXtXbZSWomlOCPRUIu5qDgRAAiEl9ImAwAA Archived-At: Subject: [OAUTH-WG] OAuth Token Swap (token chaining) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:40:40 -0000 --Apple-Mail=_6E45F2AF-E9F9-4412-BB88-988FDCA71F0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As mentioned in today=E2=80=99s IETF meeting, here are the two drafts = dealing with generic token swap: https://tools.ietf.org/html/draft-hunt-oauth-chain-01 https://tools.ietf.org/html/draft-richer-oauth-chain-00 --Apple-Mail=_6E45F2AF-E9F9-4412-BB88-988FDCA71F0D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVEGwyAAoJEDPAngkbd+w98pMH/2HbXw3TARn0XkhXIi2AXz36 ljMZlOUgLpHXEIaDSV8m/bzd2oFgwb5eeFnNNK+C7D8zMDPF1daG6vCYMIEhgY++ 0FSBm+lFh6LSj29I+xHRX7KX9WhU+gQjZ3AzL278+Vrh1eyXUx/Wc7v3c4vW4ahk KAZpgJ+juOIW+nQk+myCyVzTDhsmZCKiXDnXqcFydBWnIHCV8y6hoUf3Lmc4S0qL 4Q+sjSdggZ/dim9ci6d3z6vLi/FBmuI5syUcqxssQtGxWdx/7wo0Q1i0NfOT29iq ZOAbiDJkaqMwccRi28w8p6mF59QWzvVKE9YEEuqBxCqWT5lWdBzzjOp6AcWgb/E= =cA4o -----END PGP SIGNATURE----- --Apple-Mail=_6E45F2AF-E9F9-4412-BB88-988FDCA71F0D-- From nobody Mon Mar 23 13:20:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170941AD49B for ; Mon, 23 Mar 2015 13:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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-YfABIO1fbm for ; Mon, 23 Mar 2015 13:20:19 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::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 60CC01B29CA for ; Mon, 23 Mar 2015 13:20:19 -0700 (PDT) Received: by iedm5 with SMTP id m5so45247216ied.3 for ; Mon, 23 Mar 2015 13:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YzsA+3wgBzhydAQsqce+uypq9B5vKSw7m1FWAmouGT4=; b=bjIXUoAYYnU6cDz3CCUJmjunCDHP2OD7QC/XrW9eHN2tJFAR1SwvD9/baDZxr+v/VI ZfaQY6+13DkyAyhX+bx7yDNot4YTjclLA4+ggt+qvX7BVPwz7EL5UJcKgd2vS+kt2ZF1 DBWqVy5gUTTMdBOvr7VHcsCpBekHBFjao0muRpcIdhLP/nQteNI0+hdfnImMKmzuKqpA IkZ7W7Z/Trv9IKNXyCjmXo78bLdnLfWOYDo1hQCTbIgv6QqZxSxIUoTnbpJ+NNRzaQxv StSMfjA4ZRS6BhWPhqNriqKVszlIeQ5uiB1pbRw30LceySBNjQypst3A2sdXfah0CmyV qbqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YzsA+3wgBzhydAQsqce+uypq9B5vKSw7m1FWAmouGT4=; b=WGVzZO9xORIUBgnq5LTOn/c49X4ZnPAmbcN5yIvcYihgRYfr99fhAy0559kfqXj8XO la5eYENyFXfgiwNIybvebE4XoCX098HWM2xsWXnms8xbZElnVHkPR+ruqgfvYwsPkPLP i8+MKgFm6/A9XDYQ2spwtU7bKi7it0KytSTuT4xXAH3p8zcVkNLA6cBIP9PHdFCYl4Wp DZyTO4uUlXiyjFQso8P46YdcVPvF2X+RMER4KEVS3okfZRA75odK8qqNP4CYL5e/xIEL yqIZA0ohfUaLO+UcRp3y8VhLr3vxw0dk3vIO9FE+fCmMRgYjmIuKUdubjzF7h1nsFy81 AHBg== X-Gm-Message-State: ALoCoQmo/4lCJ/JIxL0CUXFPDPPtfV7OCMAZRpnkZ9ZE+7i6UtW3Wl9Jpoxiys0PXJV21QcnwkYV X-Received: by 10.43.142.5 with SMTP id jg5mr10588428icc.33.1427142018873; Mon, 23 Mar 2015 13:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.7 with HTTP; Mon, 23 Mar 2015 13:19:48 -0700 (PDT) In-Reply-To: References: From: Jamie Nicolson Date: Mon, 23 Mar 2015 13:19:48 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a11c2da1a145ec00511fa6526 Archived-At: Cc: "kitten@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:20:21 -0000 --001a11c2da1a145ec00511fa6526 Content-Type: text/plain; charset=UTF-8 Gmail always returns a non-empty scope value in our error response, so the proposed protocol change would not affect our implementation. On Sun, Mar 22, 2015 at 10:26 PM, Benjamin Kaduk wrote: > Hi all, > > During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed > an old comment from Matt back in December 2013, in > http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html . > > The relevant point here is that sending a scope of "" (the empty string) > during the authorization request violates the ABNF in RFC 6749. (The > other concerns seem to have been addressed by suggesting that a single > scope be used, when recommending against a space-separated list.) > > In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Server > Response to Failed Authentication"), we provide a way for the server to > tell the client what scope to use, in a custom JSON message defined in the > sasl-oauth document. This error response has no obligation to comply to > the ABNF of RFC 6749, so saying both that the scope field is optional and > that it "may be empty which implies that unscoped tokens are required, or > a scope value" does not cause any compliance issues. However, a few > paragraphs down, we furthermore say that "[i]f the resource server > provides no scope to the client then the client SHOULD presume an empty > scope (unscoped token) is required to access the resource." The phrase > "empty scope" here is concerning, and seems to suggest sending scope="", > which is disallowed by RFC 6749. > > The simple fix would be to just replace "empty scope (unscoped token)" > with "unscoped token". > > However, it is a bit aesthetically unpleasing to have our new JSON > structure diverge from the existing ABNF guidelines; we may wish to just > utilize the optionality of the scope field in the server's response to > failed authentication, and remove the mention of an empty value for that > field. This proposal is a change to the wire protocol, and so we would > need consensus from the working group to move forward with it -- in > particular, we would like to know if there are existing implementations > which would be affected by this change. > > Please comment about the proposal to remove the option of an empty scope > in the server's response to failed authentication, both from the protocol > change standpoint and from its effects on existing implementations. > > Thank you, > > Ben > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c2da1a145ec00511fa6526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gmail always returns a non-empty scope value in our error = response, so the proposed protocol change would not affect our implementati= on.

On Sun, = Mar 22, 2015 at 10:26 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:<= br>
Hi all,

During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed an old comment from Matt back in December 2013, in
http://www.ietf.org/mail-archive/web/kitten/current/ms= g04488.html .

The relevant point here is that sending a scope of "" (the empty = string)
during the authorization request violates the ABNF in RFC 6749.=C2=A0 (The<= br> other concerns seem to have been addressed by suggesting that a single
scope be used, when recommending against a space-separated list.)

In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Ser= ver
Response to Failed Authentication"), we provide a way for the server t= o
tell the client what scope to use, in a custom JSON message defined in the<= br> sasl-oauth document.=C2=A0 This error response has no obligation to comply = to
the ABNF of RFC 6749, so saying both that the scope field is optional and that it "may be empty which implies that unscoped tokens are required,= or
a scope value" does not cause any compliance issues.=C2=A0 However, a = few
paragraphs down, we furthermore say that "[i]f the resource server
provides no scope to the client then the client SHOULD presume an empty
scope (unscoped token) is required to access the resource."=C2=A0 The = phrase
"empty scope" here is concerning, and seems to suggest sending sc= ope=3D"",
which is disallowed by RFC 6749.

The simple fix would be to just replace "empty scope (unscoped token)&= quot;
with "unscoped token".

However, it is a bit aesthetically unpleasing to have our new JSON
structure diverge from the existing ABNF guidelines; we may wish to just utilize the optionality of the scope field in the server's response to<= br> failed authentication, and remove the mention of an empty value for that field.=C2=A0 This proposal is a change to the wire protocol, and so we woul= d
need consensus from the working group to move forward with it -- in
particular, we would like to know if there are existing implementations
which would be affected by this change.

Please comment about the proposal to remove the option of an empty scope in the server's response to failed authentication, both from the protoc= ol
change standpoint and from its effects on existing implementations.

Thank you,

Ben

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

--001a11c2da1a145ec00511fa6526-- From nobody Mon Mar 23 13:44:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEAE1B29F0 for ; Mon, 23 Mar 2015 13:44:19 -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] autolearn=ham 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 X1FB88UP1YEB for ; Mon, 23 Mar 2015 13:44:18 -0700 (PDT) Received: from mail-qg0-f99.google.com (mail-qg0-f99.google.com [209.85.192.99]) (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 D57D21B2A05 for ; Mon, 23 Mar 2015 13:44:17 -0700 (PDT) Received: by qgdq107 with SMTP id q107so4812437qgd.2 for ; Mon, 23 Mar 2015 13:44:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type :content-transfer-encoding:mime-version; bh=AmQXhezyOil47TQ05EuYqZNpYWVCx0GkE0N85j6AkNk=; b=Ty9q866oA4GttqJT1e/+gvBYYuymz1zA5vn5P4tlV8r+ce+3n6fSE4/+KlZiokqA6l goxYoTL9bkwvPaOruMGgTzjuFGIJeay4XjDczaOTeBI9YFa9F7Iq05vOatVmhjZGHRI0 6uRZxhZpAbe4UnzkTuMgoN75J9+Y2SGN0smKY5GIYJ1MVRRQhnRuW7ne9hGcwb9arpgR bRqYZ7+E83mVpwYGlqdXbahEjaL/f3GJQqbApl38VROUFw0ss6ux8yx88InmknlyZpHE ggnMjRVFBvCZVIogNpbMh2upiZk9h8YGjpDu3bYG0zaiBTHdU05KiUrWRoWJSk4qAOfS S7dw== X-Gm-Message-State: ALoCoQkWoHErenIOxO4NYXDhIUbqHxoySgCMjMsgEtWY4SE5M8s1ecBb8bFmOlhSWzYEgGucjzTtm1QCAooJPS5q7VSZJbgUAg== X-Received: by 10.43.38.144 with SMTP id ti16mr21877419icb.26.1427143457155; Mon, 23 Mar 2015 13:44:17 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id k1sm466531ige.0.2015.03.23.13.44.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Mar 2015 13:44:17 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t2NKiGdu017734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Mar 2015 16:44:16 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 23 Mar 2015 16:44:16 -0400 From: "Hollenbeck, Scott" To: "OAuth@ietf.org" Thread-Topic: Federated Authentication for RDAP Thread-Index: AdBlqh91tPNa5rKhRa+xxzcblJ8Kcg== Date: Mon, 23 Mar 2015 20:44:15 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F8A017@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Federated Authentication for RDAP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:44:19 -0000 I was going to ask this question during the just-concluded WG session at IE= TF-92, but with a full agenda and little time I thought it might be better = to ask this question on-list. The Registration Data Access Protocol (RDAP, a work product of the WEIRDS W= G) uses a RESTful web service to access data associated with things like do= main names and IP address blocks. It's intended to be a replacement for the= aged WHOIS protocol. I co-authored a security services document for RDAP t= hat describes how a federated authentication system can address an operatio= nal need for client identification, authentication, and authorization, but = that document doesn't specify any particular solution or how it can actuall= y be deployed. In the near future implementers will be standing up services= and I'd like explore some workable options. So, I'm looking for advice fro= m people who know more about federated authentication systems than I do. RDAP clients will be the same type of people who use WHOIS today. Servers w= ill need to be able to identify and authenticate clients and grant appropri= ate privileges based on their identity and purpose. What kind of federation= could be deployed today to meet these needs? Which protocol(s) will do the= job and be brain-dead simple for human end users? Scott From nobody Mon Mar 23 14:22:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1A1A1AD0 for ; Mon, 23 Mar 2015 14:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 dhlXmgOaJlbN for ; Mon, 23 Mar 2015 14:22:15 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D19E1A1B1E for ; Mon, 23 Mar 2015 14:22:13 -0700 (PDT) Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKVRCEBVrCx7OwFesyAwqZT/nVUX+/kY8x@postini.com; Mon, 23 Mar 2015 14:22:13 PDT Received: by iecvj10 with SMTP id vj10so46492129iec.0 for ; Mon, 23 Mar 2015 14:22:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qoAVbBqDm+0DtQ4lIuaJBOzTu8OxG9gNcgmF2Az+hFs=; b=RyC1aHCC6/qhBV73sPUmomTdgAVkZCZNKC8ZnlJRJKDo69iYBFSDXdiHYRwJUBkAKe fWnGcczzdB+OGWo1a+bBD7U6FTrBIL1FcNhyr7eiRP+QZxNPvc7d2MI9Uun8Af3EOlu5 98LspxTdDrFJiOxnMSXSXwxjAGJ0yHgriM1yDYvMloOwFeFy+QBtmxkDICw2dF3xILIi yVDqsUsJkaWLe1HPEkfJMf764lx3jdR6kDHBvPh3YYBUHZRf0HdP1Vh+l637mHuU4Acj YHVlLiWa3X/1vVqb8J8tSXy5cjvuQ7m2ipwJcV7tPtMMZmoCc826USAJKkuoOqyq72Sh wMqg== X-Gm-Message-State: ALoCoQlH6z2TvullAOtN7TuQpOp0jvLgjpaDVwqWQVhY7K9bsmzQFs2L1J2W6DdvxeaW/10I5hFgahjVkPNORFm6u/9TNewNSKnKXEnXLsJxQbPDDsKSTxaFoUMXhPqEyI16TUW6QG0J X-Received: by 10.107.10.82 with SMTP id u79mr1706297ioi.65.1427145732806; Mon, 23 Mar 2015 14:22:12 -0700 (PDT) X-Received: by 10.107.10.82 with SMTP id u79mr1706279ioi.65.1427145732668; Mon, 23 Mar 2015 14:22:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Mon, 23 Mar 2015 14:21:41 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 23 Mar 2015 16:21:41 -0500 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a113f9b4a7056a60511fb42b3 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:22:17 -0000 --001a113f9b4a7056a60511fb42b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, kid could do it. It just seemed less than idea and that, for confirmation, it might be useful to explicitly say "this is the thumbprint of the key that'll confirm this JWT" rather than "here's something that points to a key for confirmation and in some cases it might be a thumbprint". But I just wanted to ask the question to gauge interest. And it seems there's not much. It could be added later too, if more need for it arises. On Mon, Mar 23, 2015 at 1:55 PM, Nat Sakimura wrote: > ok, this is a full circle to my original comment "Would not kid do? " > 2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 13:52 Brian Campbell : > > I wasn't necessarily suggesting to drop the kid one. >> >> On Mon, Mar 23, 2015 at 1:00 PM, Nat Sakimura wrote= : >> >>> +1 for dropping kid in favor of thumbprint. >>> 2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 12:56 Brian Campbell : >>> >>> Yeah, it could be done with kid. But that would require a bit more >>>> out-of-band understanding between the parties to know that the kid is,= in >>>> fact, a thumbprint. Seems like it'd be better to outright support a >>>> thumbprint rather than overloading kid, if thumbprint representation o= f the >>>> key for confirmation is desirable. >>>> >>>> And yes, a thumbprint does have some nice properties. But I am also >>>> very sympathetic to the "too many ways is not good for interop" point. >>>> That's kind of why I asked what others thought of it rather than just >>>> making a suggestion. I'm not sure one way or the other myself. >>>> >>>> On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura >>>> wrote: >>>> >>>>> Would not kid do? >>>>> Right, thumbprint has more semantics and has nice properties, but >>>>> having too many ways is not good for interop. >>>>> >>>>> Nat >>>>> >>>>> 2015-03-23 15:40 GMT+09:00 Brian Campbell >>>>> : >>>>> >>>>>> Do folks in the WG think there'd be utility in having a way to >>>>>> identity the finger/thumbprint of a key in the cnf claim. A presente= r >>>>>> might, for example, present the JWT along with a public JWK and some >>>>>> proof-of-possession of that JWK. And the JWK would be bound to the = JWT via >>>>>> the thumbprint, which is more space efficient (with respect to the J= WT >>>>>> anyway) than the full JWK. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >> --001a113f9b4a7056a60511fb42b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, kid could do it. It just seemed less than idea and th= at, for confirmation, it might be useful to explicitly say "this is th= e thumbprint of the key that'll confirm this JWT" rather than &quo= t;here's something that points to a key for confirmation and in some ca= ses it might be a thumbprint".

But I just wanted to ask the question to gauge interest. And it seems ther= e's not much. It could be added later too, if more need for it arises. =

On Mon,= Mar 23, 2015 at 1:55 PM, Nat Sakimura <sakimura@gmail.com>= wrote:
ok, this is a full circle to my o= riginal comment "Would not kid do? "
2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C=88) 13:52 Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com>:

I wasn't necessarily suggesting to drop the kid one.

On Mon, Mar 23, = 2015 at 1:00 PM, Nat Sakimura <sakimura@gmail.com> wrote:
+1 for dropping kid in favor of thumbprint= .
2015=E5=B9=B43=E6=9C=8823=E6=97=A5(=E6=9C= =88) 12:56 Brian Campbell <bcampbell@pingidentity.com>:

Yeah, it could be done with k= id. But that would require a bit more out-of-band understanding between the= parties to know that the kid is, in fact, a thumbprint. Seems like it'= d be better to outright support a thumbprint rather than overloading kid, i= f thumbprint representation of the key for confirmation is desirable.
<= br>
And yes, a thumbprint does have some nice properties. But I am als= o very sympathetic to the "too many ways is not good for interop"= point. That's kind of why I asked what others thought of it rather tha= n just making a suggestion. I'm not sure one way or the other myself.

On Mon, M= ar 23, 2015 at 2:11 AM, Nat Sakimura <sakimura@gmail.com> w= rote:
Would not kid= do?=C2=A0
Right, thumbprint has more semantics and has nice prop= erties, but having too many ways is not good for interop.=C2=A0
<= br>
Nat

2015-03-23 15:40 GMT+09:00 Brian Campbell <bcam= pbell@pingidentity.com>:
Do folks in the WG think there'd be utility= in having a way to identity the finger/thumbprint of a key in the cnf clai= m. A presenter might, for example, present the JWT along with a public JWK = and some proof-of-possession of that JWK.=C2=A0 And the JWK would be bound = to the JWT via the thumbprint, which is more space efficient (with respect = to the JWT anyway) than the full JWK.



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



=

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en



--001a113f9b4a7056a60511fb42b3-- From nobody Mon Mar 23 23:12:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0271B2CA0; Mon, 23 Mar 2015 23:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 B52BfY3YOvUX; Mon, 23 Mar 2015 23:12:46 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (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 6EC611A8836; Mon, 23 Mar 2015 23:12:46 -0700 (PDT) Received: from [80.187.100.210] (helo=[10.132.251.125]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1YaI4x-0008BL-Vt; Tue, 24 Mar 2015 07:12:44 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----517IOCS8HCBJ0L7AJSKYP58PJB267O" Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Tue, 24 Mar 2015 07:12:41 +0100 To: Benjamin Kaduk ,kitten@ietf.org Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 06:12:50 -0000 ------517IOCS8HCBJ0L7AJSKYP58PJB267O Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Benjamin, in my opinion, your proposal sound reasonable from a protocol perspective. kind regards, Torsten. Am 23. März 2015 06:26:20 MEZ, schrieb Benjamin Kaduk : >Hi all, > >During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I >noticed >an old comment from Matt back in December 2013, in >http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html . > >The relevant point here is that sending a scope of "" (the empty >string) >during the authorization request violates the ABNF in RFC 6749. (The >other concerns seem to have been addressed by suggesting that a single >scope be used, when recommending against a space-separated list.) > >In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 >("Server >Response to Failed Authentication"), we provide a way for the server to >tell the client what scope to use, in a custom JSON message defined in >the >sasl-oauth document. This error response has no obligation to comply >to >the ABNF of RFC 6749, so saying both that the scope field is optional >and >that it "may be empty which implies that unscoped tokens are required, >or >a scope value" does not cause any compliance issues. However, a few >paragraphs down, we furthermore say that "[i]f the resource server >provides no scope to the client then the client SHOULD presume an empty >scope (unscoped token) is required to access the resource." The phrase >"empty scope" here is concerning, and seems to suggest sending >scope="", >which is disallowed by RFC 6749. > >The simple fix would be to just replace "empty scope (unscoped token)" >with "unscoped token". > >However, it is a bit aesthetically unpleasing to have our new JSON >structure diverge from the existing ABNF guidelines; we may wish to >just >utilize the optionality of the scope field in the server's response to >failed authentication, and remove the mention of an empty value for >that >field. This proposal is a change to the wire protocol, and so we would >need consensus from the working group to move forward with it -- in >particular, we would like to know if there are existing implementations >which would be affected by this change. > >Please comment about the proposal to remove the option of an empty >scope >in the server's response to failed authentication, both from the >protocol >change standpoint and from its effects on existing implementations. > >Thank you, > >Ben > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------517IOCS8HCBJ0L7AJSKYP58PJB267O Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Benjamin,

in my opinion, your proposal sound reasonable from a protocol perspective.

kind regards,
Torsten.

Am 23. März 2015 06:26:20 MEZ, schrieb Benjamin Kaduk <kaduk@MIT.EDU>:
Hi all,

During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed
an old comment from Matt back in December 2013, in
http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html .

The relevant point here is that sending a scope of "" (the empty string)
during the authorization request violates the ABNF in RFC 6749.  (The
other concerns seem to have been addressed by suggesting that a single
scope be used, when recommending against a space-separated list.)

In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Server
Response to Failed Authentication"), we provide a way for the server to
tell the client what scope to use, in a custom JSON message defined in the
sasl-oauth document.  This error response has no obligation to comply to
the ABNF of RFC 6749, so saying both that
the scope field is optional and
that it "may be empty which implies that unscoped tokens are required, or
a scope value" does not cause any compliance issues.  However, a few
paragraphs down, we furthermore say that "[i]f the resource server
provides no scope to the client then the client SHOULD presume an empty
scope (unscoped token) is required to access the resource."  The phrase
"empty scope" here is concerning, and seems to suggest sending scope="",
which is disallowed by RFC 6749.

The simple fix would be to just replace "empty scope (unscoped token)"
with "unscoped token".

However, it is a bit aesthetically unpleasing to have our new JSON
structure diverge from the existing ABNF guidelines; we may wish to just
utilize the optionality of the scope field in the server's response to
failed authentication, and remove the mention of an empty value for that
field.  This proposal is a change to the wire
protocol, and so we would
need consensus from the working group to move forward with it -- in
particular, we would like to know if there are existing implementations
which would be affected by this change.

Please comment about the proposal to remove the option of an empty scope
in the server's response to failed authentication, both from the protocol
change standpoint and from its effects on existing implementations.

Thank you,

Ben


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

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------517IOCS8HCBJ0L7AJSKYP58PJB267O-- From nobody Tue Mar 24 05:55:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DACC1A00DC for ; Tue, 24 Mar 2015 05:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 uyP_zhHt5hZk for ; Tue, 24 Mar 2015 05:55:41 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D6E1A00BF for ; Tue, 24 Mar 2015 05:55:40 -0700 (PDT) Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKVRFezIMNyVvz27+lxiJ4GOknCGGydPeC@postini.com; Tue, 24 Mar 2015 05:55:40 PDT Received: by iecvj10 with SMTP id vj10so59318669iec.0 for ; Tue, 24 Mar 2015 05:55:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc:content-type; bh=d3qUSJkhZ76wyoqnXun+g70YRYNccypcbb7p1+9xYP4=; b=P71OsYpg6xUadB4EEhgd7IhlO3AMMZyEvRwUrQR2cJxfsVgINBuTEq65rHqLRkBEll Sz/P9HWVrzxs7QLjZX6U9+mvOh452Ha9xqfM8CR2g1h71/xHeWs8kohxQDJCpKMwvCcy FCAy8tMD55/p9uTHW7jLkM2t4XYhD4Fpa7g9PKNP3I+wqArq3841zOFxxMzlf0fDN3xn JuP382ZTJbE5Dq3Cph+cra0Ycsr2XHVymgM10NiM3SF6a7dmRmqPpgSr1/iLIVx1bUpM xJwsC24bI/9bvruQPsi0RUYixgqDQL0Mcx6VHgifpir+2pV+KROf3+EjG7WoEkwByhqs 5amw== X-Gm-Message-State: ALoCoQmRxiI7lKzahJ7A9f40v6cShBsXUia3Wi4NMVm5q3P1argKMYhKJcpQk5CWrZ/Ib2QwjC3H1pBRRiaKXY0Af/WoAvto01VFU8yCseR8rkhqQc9bjzsNDOn+VSTSbEN4K2DPnew+ X-Received: by 10.50.1.48 with SMTP id 16mr22135319igj.45.1427201740309; Tue, 24 Mar 2015 05:55:40 -0700 (PDT) X-Received: by 10.50.1.48 with SMTP id 16mr22135309igj.45.1427201740194; Tue, 24 Mar 2015 05:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Tue, 24 Mar 2015 05:55:10 -0700 (PDT) In-Reply-To: <0C7C1508-DA58-4832-B755-F8BA1F153894@mit.edu> References: <0C7C1508-DA58-4832-B755-F8BA1F153894@mit.edu> From: Brian Campbell Date: Tue, 24 Mar 2015 07:55:10 -0500 Message-ID: Cc: "" Content-Type: multipart/alternative; boundary=047d7bdc12b0bf5b170512084c93 Archived-At: Subject: Re: [OAUTH-WG] OAuth Token Swap (token chaining) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 12:55:42 -0000 --047d7bdc12b0bf5b170512084c93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And here's the somewhat different take on token exchange that I mentioned yesterday: https://tools.ietf.org/html/draft-campbell-oauth-sts-01 A little more background, context, and discussion about it can be seen following the thread on the Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth WG Item: https://www.ietf.org/mail-archive/web/oauth/current/msg13236.html https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html ... etc ... https://www.ietf.org/mail-archive/web/oauth/current/msg13311.html ... etc. On Mon, Mar 23, 2015 at 2:40 PM, Justin Richer wrote: > As mentioned in today=E2=80=99s IETF meeting, here are the two drafts dea= ling with > generic token swap: > > https://tools.ietf.org/html/draft-hunt-oauth-chain-01 > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7bdc12b0bf5b170512084c93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And here's the somewhat different take on token e= xchange that I mentioned yesterday:
https://tools.ietf.org/ht= ml/draft-campbell-oauth-sts-01

A little more background, context= , and discussion about it can be seen following the thread on the Call for = Adoption of "OAuth 2.0 Token Exchange" as an OAuth WG Item:
https://www.ietf.org/mail-archive/web/oauth/current/msg1= 3236.html
https://www.ietf.org/mail-archive/web= /oauth/current/msg13305.html
... etc ...




On Mon, Mar 23, 2015 at 2:40 PM, Justin = Richer <jricher@mit.edu> wrote:
As mentioned in today=E2=80=99s IETF meeting, here a= re the two drafts dealing with generic token swap:

https://tools.ietf.org/html/draft-hunt-oauth-chain-01
https://tools.ietf.org/html/draft-richer-oauth-chain-00

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


--047d7bdc12b0bf5b170512084c93-- From nobody Tue Mar 24 06:42:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB091A6FF1 for ; Tue, 24 Mar 2015 06:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E09iCfUkfcES for ; Tue, 24 Mar 2015 06:42:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.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 01C841A6FCF for ; Tue, 24 Mar 2015 06:42:10 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2ODgAUP000454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 24 Mar 2015 09:42:10 -0400 Received: from [10.10.51.120] (unused [10.10.51.120] (may be forged)) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2ODg9fs027933 for ; Tue, 24 Mar 2015 09:42:10 -0400 Message-ID: <551169B2.5020104@redhat.com> Date: Tue, 24 Mar 2015 09:42:10 -0400 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: oauth@ietf.org References: <0C7C1508-DA58-4832-B755-F8BA1F153894@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [OAUTH-WG] OAuth Token Swap (token chaining) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 13:42:17 -0000 On 3/24/2015 8:55 AM, Brian Campbell wrote: > And here's the somewhat different take on token exchange that I > mentioned yesterday: > https://tools.ietf.org/html/draft-campbell-oauth-sts-01 > I'm unclear how your STS would work. Is your client required to go through the whole OAuth process to obtain an access token on behalf of the user before it can invoke on the STS? Or can it be granted tokens for any user out of band without user consent or user authorization? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Tue Mar 24 06:43:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1121A6FF1 for ; Tue, 24 Mar 2015 06:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QpyMZO1H4b_J for ; Tue, 24 Mar 2015 06:43:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD651A702B for ; Tue, 24 Mar 2015 06:43:22 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2ODhKMt026426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Mar 2015 13:43:21 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2ODhK5r020001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2015 13:43:20 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2ODhK8i007900; Tue, 24 Mar 2015 13:43:20 GMT Received: from [31.133.140.83] (/31.133.140.83) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Mar 2015 06:43:20 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-FD6B5FC6-3DC1-4551-968B-7D11DE5BA3B9 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 24 Mar 2015 08:43:17 -0500 Content-Transfer-Encoding: 7bit Message-Id: <080772BA-7A36-4E49-A4AD-50ABEEAF1427@oracle.com> References: <0C7C1508-DA58-4832-B755-F8BA1F153894@mit.edu> To: Brian Campbell X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth Token Swap (token chaining) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 13:43:26 -0000 --Apple-Mail-FD6B5FC6-3DC1-4551-968B-7D11DE5BA3B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As the original author, I don't know why this issue has not been followed th= rough on. Still it has given me about 3 years to reflect. :-) I support any of these drafts going forward but I think we have to think thr= ough performance issues.=20 I concluded that a swap should only be done, if at all, when an edge server w= ants to access a foreign domain as the inbound AT may be opaque. Otherwise p= assing the original AT in another header plus a service token for the edge s= erver in the authentication header might be more scalable. The edge server t= oken is long-lived and the same-domain internal server can parse or introspe= ct both tokens to understand actas etc. in either method the authenticated c= ontext carries the primary security credential. =20 For the internal case, the value of a token swipe is lost since consent is i= mplicit and probably does not need to be double-checked each time.=20 Phil > On Mar 24, 2015, at 07:55, Brian Campbell wro= te: >=20 > And here's the somewhat different take on token exchange that I mentioned y= esterday: > https://tools.ietf.org/html/draft-campbell-oauth-sts-01 >=20 > A little more background, context, and discussion about it can be seen fol= lowing the thread on the Call for Adoption of "OAuth 2.0 Token Exchange" as a= n OAuth WG Item: > https://www.ietf.org/mail-archive/web/oauth/current/msg13236.html > https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html > ... etc ... > https://www.ietf.org/mail-archive/web/oauth/current/msg13311.html > ... etc. >=20 >=20 >=20 >=20 >> On Mon, Mar 23, 2015 at 2:40 PM, Justin Richer wrote: >> As mentioned in today=E2=80=99s IETF meeting, here are the two drafts dea= ling with generic token swap: >>=20 >> https://tools.ietf.org/html/draft-hunt-oauth-chain-01 >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 >>=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 --Apple-Mail-FD6B5FC6-3DC1-4551-968B-7D11DE5BA3B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As the original author, I don't know w= hy this issue has not been followed through on. Still it has given me about 3= years to reflect. :-)

I support any of these draft= s going forward but I think we have to think through performance issues.&nbs= p;

I concluded that a swap should only be done, if a= t all, when an edge server wants to access a foreign domain as the inbound A= T may be opaque. Otherwise passing the original AT in another header plus a s= ervice token for the edge server in the authentication header might be more s= calable. The edge server token is long-lived and the same-domain internal se= rver can parse or introspect both tokens to understand actas etc.  in e= ither method the authenticated context carries the primary security credenti= al.  

For the internal case, the value of a to= ken swipe is lost since consent is implicit and probably does not need to be= double-checked each time. 

Phil

On Mar 24,= 2015, at 07:55, Brian Campbell <bcampbell@pingidentity.com> wrote:

And here's the somewhat different take= on token exchange that I mentioned yesterday:
https://tools.ie= tf.org/html/draft-campbell-oauth-sts-01

A little more background,= context, and discussion about it can be seen following the thread on the Ca= ll for Adoption of "OAuth 2.0 Token Exchange" as an OAuth WG Item:
https://www.ietf.org/mail-archive/web/oauth/current/msg13236.h= tml
https://www.ietf.org/mail-archive/web/oauth/c= urrent/msg13305.html
... etc ...
ht= tps://www.ietf.org/mail-archive/web/oauth/current/msg13311.html
... etc.




On Mon, Mar 23, 2015 at 2:40 PM, Justin Richer <jricher@= mit.edu> wrote:
As mentioned in today=E2=80=99s IETF meeting, here are the two drafts d= ealing with generic token swap:

https://tools.ietf.org/html/draft-hunt-oauth-chain-01
https://tools.ietf.org/html/draft-richer-oauth-chain-00

_______________________________________________
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-FD6B5FC6-3DC1-4551-968B-7D11DE5BA3B9-- From nobody Tue Mar 24 08:21:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DBC1A88AE; Tue, 24 Mar 2015 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5S5nuJQiHP68; Tue, 24 Mar 2015 08:21:27 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ACB51A88C7; Tue, 24 Mar 2015 08:21:26 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-06-551180f57274 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.04.03700.5F081155; Tue, 24 Mar 2015 11:21:25 -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 t2OFLO1g026845; Tue, 24 Mar 2015 11:21:24 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2OFLMRT013395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2015 11:21:23 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2OFLLpI003217; Tue, 24 Mar 2015 11:21:21 -0400 (EDT) Date: Tue, 24 Mar 2015 11:21:21 -0400 (EDT) From: Benjamin Kaduk To: Torsten Lodderstedt In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrfu1QTDU4MMnHoujm1exWJx8+4rN 4tWxpywOzB5Llvxk8jjW088awBTFZZOSmpNZllqkb5fAlbHpyin2gilMFUePnWRpYLzC2MXI ySEhYCIx8eJdKFtM4sK99WxdjFwcQgKLmSR2/DvPDOFsZJTYvPs2E4RziEli/+wXrBBOA6PE 37c97CD9LALaEutXnmIFsdkEVCRmvtnIBmKLCBhKtE9cyAxiMwsoSzR/OwpWLywQIPHtzwww m1PAWeLs4s8sIDavgKPE7yfzwOJCAhUSy7ZfBIuLCuhIrN4/BapGUOLkzCcsEDO1JJZP38Yy gVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYLClt1FeQfj n4NKhxgFOBiVeHgDlgiECrEmlhVX5h5ilORgUhLlne4kGCrEl5SfUpmRWJwRX1Sak1p8iFGC g1lJhHdtPVCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCdwpIo2BR anpqRVpmTglCmomDE2Q4D9Dwx2DDiwsSc4sz0yHypxh1Oe5M+b+ISYglLz8vVUqctxOkSACk KKM0D24OLN28YhQHekuYdx9IFQ8wVcFNegW0hAloybl8PpAlJYkIKakGRvYC0fe7F8x56vTi 4tYvfL6i19k3vJgjznS1mW2zo+rhe4lHDl1VPq5bdt2tRLOWpeFKy5MWpe45a76ezTTmVBII nrV2mnVyXsdNxmVL/druVW+N7T8TzSbxXll+em/+wj0s76coZz4L+C+w1VTjV/QZ5elp6TFy TjWT02++er7AZvaPshsX5yuxFGckGmoxFxUnAgAEPtrqEgMAAA== Archived-At: Cc: kitten@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:21:29 -0000 Hi Torsten, On Tue, 24 Mar 2015, Torsten Lodderstedt wrote: > Hi Benjamin, > > in my opinion, your proposal sound reasonable from a protocol perspective. I should clarify that Bill came up with the idea; I just sent the mail. Thank you for reviewing it. -Ben From nobody Tue Mar 24 08:29:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3BE1A890D; Tue, 24 Mar 2015 08:29:02 -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] autolearn=ham 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 Rg9glmJ3jZ2A; Tue, 24 Mar 2015 08:29:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 429121A88F9; Tue, 24 Mar 2015 08:28:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324152859.26937.50628.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 08:28:59 -0700 Archived-At: Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org Subject: [OAUTH-WG] IPR Disclosure Kirsten Aldrich's Statement about IPR related to RFC 6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:29:02 -0000 Dear Dick Hardt: An IPR disclosure that pertains to your RFC entitled "The OAuth 2.0 Authorization Framework" (RFC6749) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2561/). The title of the IPR disclosure is "Kirsten Aldrich's Statement about IPR related to RFC 6749" Thank you IETF Secretariat From nobody Tue Mar 24 08:35:05 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AB11A8927 for ; Tue, 24 Mar 2015 08:35: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, SPF_PASS=-0.001] autolearn=ham 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 rUT-pw5Uj3GB for ; Tue, 24 Mar 2015 08:35:02 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 817201A8902 for ; Tue, 24 Mar 2015 08:35:02 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so49312244lbb.3 for ; Tue, 24 Mar 2015 08:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vXBI1OORr0dxS3eRYVQYH9Y4iHaWE28NoJk5EDdpdfo=; b=C6ZaSFWnPlzZfa+dQ5+x4m3rE+bkpPv0IpHhhctqLiAK2DQTvZ5zoQ6gRN0MWlKq4S 7GdSizfusqkZvgt+QUq2b4kc0e/23QG2rayt+MXwaClZI0jtt31GJqO/b/4p3ggO9HYz DATRdHIIRq8NXOF9rTFJPluH8tM97vJv9PtY5SXGZL5gptXyLeXpuMZ1VZI7I7tZiY5s s58hB+MMziJUdlFBncEMEYErYGBdacGcWbtAtewp7AJ+vGLpx7d4FUkfqKKki9+ZXnds 29tBPsUhyK7EH3heqjMM0DDD23uNbhCDtYrG87IP4BbpILCve6EtULP1GKh1NQ8c5uj7 TxJw== MIME-Version: 1.0 X-Received: by 10.112.188.227 with SMTP id gd3mr4502460lbc.0.1427211301083; Tue, 24 Mar 2015 08:35:01 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 24 Mar 2015 08:35:01 -0700 (PDT) Date: Tue, 24 Mar 2015 11:35:01 -0400 Message-ID: From: Kathleen Moriarty To: Justin Richer , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c36aa89edda105120a86fa Archived-At: Subject: [OAUTH-WG] updates on drafts in IESG processing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:35:04 -0000 --001a11c36aa89edda105120a86fa Content-Type: text/plain; charset=UTF-8 Hi Justin, I believe you said there was some pending updates for the dyn-reg draft for which there is already a ballot. If that's correct, please go ahead and post the updated version. If I am wrong and we are just waiting on the management one, I'll add the ballot once you let me know the posted version is ready for IESG review. -- Best regards, Kathleen --001a11c36aa89edda105120a86fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Justin,

I believe you said there was= some pending updates for the dyn-reg draft for which there is already a ba= llot.=C2=A0 If that's correct, please go ahead and post the updated ver= sion.=C2=A0 If I am wrong and we are just waiting on the management one, I&= #39;ll add the ballot once you let me know the posted version is ready for = IESG review.

--

Best regards,
Kathleen
--001a11c36aa89edda105120a86fa-- From nobody Tue Mar 24 08:36:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3261B1A88EB for ; Tue, 24 Mar 2015 08:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VPE3QV1zBJl0 for ; Tue, 24 Mar 2015 08:36:41 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6053B1A8953 for ; Tue, 24 Mar 2015 08:36:40 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-57-55118487c9f0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 05.95.03700.78481155; Tue, 24 Mar 2015 11:36:39 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t2OFacx5004429; Tue, 24 Mar 2015 11:36:38 -0400 Received: from [172.30.10.84] ([12.184.28.200]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2OFaZS6018963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2015 11:36:37 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DCA25000-BC16-4B98-AB0C-05F18EA01740"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: Date: Tue, 24 Mar 2015 10:36:35 -0500 Message-Id: <0989701D-EBF9-4F57-8AEA-FD21A22C43C6@mit.edu> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOKsWRmVeSWpSXmKPExsUixG6notveIhhqsO8Ev0XDznyLpidr2S1O vn3F5sDssXPWXXaPJUt+Mnm07vjLHsAcxWWTkpqTWZZapG+XwJVx6vsu9oLvvBWfdx1gaWD8 yd3FyMkhIWAisfjqPhYIW0ziwr31bCC2kMBiJonWvwVdjFxA9kZGiefXtjJBJNYwScw5VwRi CwsYSvya1MwKYvMKGEjMPfUFrIZZYAqjxP33YhBDpSSaXh9jBLHZBFQl5q+8BVbDKRAocehu G9hiFqD46+4/jBC9XhIr7h1khphpJTHv2GVWiL0BEg+fPAY7TkTAQmJN8zcgmwNovrxEz6b0 CYyCs5BcMQvJFRC2tsSyha+ZIWxNif3dy1kgbHmJ7W/nQMUtJRbPvAEVt5W41bcAao6dxKNp i1gXMHKsYpRNya3SzU3MzClOTdYtTk7My0st0jXTy80s0UtNKd3ECI4jF+UdjH8OKh1iFOBg VOLhDVgiECrEmlhWXJl7iFGSg0lJlHe6k2CoEF9SfkplRmJxRnxRaU5q8SFGFaBdjzasvsAo xZKXn5eqJMJr1AxUx5uSWFmVWpQPUybNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgjcJ pFGwKDU9tSItM6cEIc3EwXmIUYKDB2i4Btjw4oLE3OLMdIj8KUZFKXFebpCEAEgiozQPrheW /l4xigO9JczrCVLFA0ydcN2vgAYzAQ0+l88HMrgkESEl1cCYvHn6hcO6wWx+/58/qJnE3GDy UPbjfoGJ6Ra5W1nqqnIV7P5Jr7cIWJc+c2ns3dfxkal/1xRumyt4/tX/mt97W9O3dQnoHDPi +Zo7OYx7pQmj/EXJg5utAr9squuWmCwRuXL22ZVZF740c/HsOO8d6BC6/ebmlGYpp+133bky pTwTfonzznFTYinOSDTUYi4qTgQAt87u+1oDAAA= Archived-At: Cc: Michael Jones , "" Subject: Re: [OAUTH-WG] updates on drafts in IESG processing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:36:46 -0000 --Apple-Mail=_DCA25000-BC16-4B98-AB0C-05F18EA01740 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, There are some minor changes needed to bring the two IANA registry = sections in sync with each other. Mike Jones and I are going to sit down = this afternoon and put that together, we=E2=80=99ll let you know as soon = as those are available. Should be posted by this evening though. Thank you, =E2=80=94 Justin > On Mar 24, 2015, at 10:35 AM, Kathleen Moriarty = wrote: >=20 > Hi Justin, >=20 > I believe you said there was some pending updates for the dyn-reg = draft for which there is already a ballot. If that's correct, please go = ahead and post the updated version. If I am wrong and we are just = waiting on the management one, I'll add the ballot once you let me know = the posted version is ready for IESG review. >=20 > -- >=20 > Best regards, > Kathleen --Apple-Mail=_DCA25000-BC16-4B98-AB0C-05F18EA01740 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVEYSEAAoJEDPAngkbd+w9gJkIAJNX5twBrhIfCHY7C8nUWgLO gQfDoFbwTuRSn0n8kf9Ouk4laVQu7rWLwZ9b49ubqIKmGcxd+63wyw5cAk++momN AZ+T1O4tVCDyfgFKusz/kYpAUYf06rWPJvtB3hvlq5SeE3aQ6GjQeeYNjxf10FuY kwIlACdjRCuBa9V8OK0EkKTwZWtOqlyJ7eofQoypQ96d6aCKk5HO7L1d57/lno0x UJ/CV5HxoUW+XlRWMBEf7hhyyHUCN4KP4WRR7qv9qEqY68OT3RDuV3KIxYcgtuBo 8NHlgKWzGjp2X+1W4qwyKRIIm8jysqIcjUInmb3M3HtU3X/uT+l4eCOM8ss5DOY= =Yrpx -----END PGP SIGNATURE----- --Apple-Mail=_DCA25000-BC16-4B98-AB0C-05F18EA01740-- From nobody Tue Mar 24 08:38:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A1F1A8988 for ; Tue, 24 Mar 2015 08:38:30 -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] autolearn=ham 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 iZID2Rpo4yGf for ; Tue, 24 Mar 2015 08:38:28 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145C81A8994 for ; Tue, 24 Mar 2015 08:38:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 9C0B9E2036 for ; Tue, 24 Mar 2015 11:38:11 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24114-06 for ; Tue, 24 Mar 2015 11:38:09 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 826AFE2039; Tue, 24 Mar 2015 11:38:08 -0400 (EDT) Received: from 31.133.176.247 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 24 Mar 2015 11:38:08 -0400 Message-ID: Date: Tue, 24 Mar 2015 11:38:08 -0400 From: "Derek Atkins" To: oauth@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [OAUTH-WG] [Fwd: IPR Disclosure Kirsten Aldrich's Statement about IPR related to RFC 6749] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:38:30 -0000 FYI, Just so you all are aware of this IPR filing. -derek ---------------------------- Original Message ---------------------------- Subject: IPR Disclosure Kirsten Aldrich's Statement about IPR related to RFC 6749 From: "IETF Secretariat" Date: Tue, March 24, 2015 11:28 am To: dick.hardt@gmail.com Cc: stephen.farrell@cs.tcd.ie Kathleen.Moriarty.ietf@gmail.com Hannes.Tschofenig@gmx.net derek@ihtfp.com oauth@ietf.org ipr-announce@ietf.org -------------------------------------------------------------------------- Dear Dick Hardt: An IPR disclosure that pertains to your RFC entitled "The OAuth 2.0 Authorization Framework" (RFC6749) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2561/). The title of the IPR disclosure is "Kirsten Aldrich's Statement about IPR related to RFC 6749" Thank you IETF Secretariat -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Mar 24 10:33:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E281AC3F9 for ; Tue, 24 Mar 2015 10:33:54 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AxrwQs3zaBXZ for ; Tue, 24 Mar 2015 10:33:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752501AC3F0 for ; Tue, 24 Mar 2015 10:33:45 -0700 (PDT) Received: from [192.168.10.145] ([31.133.152.120]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsChr-1Zda6z3vwN-013rwY for ; Tue, 24 Mar 2015 18:33:43 +0100 Message-ID: <55119FF4.5000904@gmx.net> Date: Tue, 24 Mar 2015 18:33:40 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vNV46kT53PNvkSVS3oDneGMWskl66Tdwl" X-Provags-ID: V03:K0:zk5jnUX/b6Q7opxAoXEkAbNaABjgSug1M+ThwuYLuMeUmFg+aTZ DpmHKOl7nDT7DP/ISASVqCTbboINknz975GUvGVmM3D8FMRyBJYHFQ1uXJWGoED4TwzYRUp LWsWayJHhVsPVL60W4ia+0etTIp/rh68qRddXcTi3EtvVS9CQbwTLlLGW/Bx2v/402fbCj4 HV/ttmPjOop76Qe5YiJlw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Informal Chat on Wednesday Evening X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:33:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vNV46kT53PNvkSVS3oDneGMWskl66Tdwl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, if you are attending the IETF meeting we would like to meet you for an informal chat about **token exchange**. We meet at the hotel reception on Wednesday, 19:10 (after the admin plenary). Ciao Hannes --vNV46kT53PNvkSVS3oDneGMWskl66Tdwl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVEZ/0AAoJEGhJURNOOiAtJpoH/jgazN/lXwcH20em6vEcu+Rg j2G6/aY9SvisF+OftKq54uF+ol4TPkJt81ndKypY57+41CRG0ppLXnfXq6fjlgpU sFbRA96dsopYHVFGjvUYgpWHfChgsjFd4LVa4/PHzqG03y8KqD6vfMELFtcmPyCs AsXw0kcaN2iQdSd/V3g2Cfx9hnvVxaHi7eGrS2OAFbIrReGhakCMLxAYzhQlvVv1 k0v60qNl9eRu7hVdTO7XtXDn2HOkmmXZDexBTjcW0puFU1YZQUzech/x1c0pG1uU /D1EKwOO8QnGw39HXEiefYP7nFvHJAXrPGzxlAsxVOCtwC6+P+qtkdWMRJk4ddM= =R0sm -----END PGP SIGNATURE----- --vNV46kT53PNvkSVS3oDneGMWskl66Tdwl-- From nobody Tue Mar 24 13:48:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5011A037B for ; Tue, 24 Mar 2015 13:48:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yYtSxodO5God for ; Tue, 24 Mar 2015 13:48:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1F01A01A5 for ; Tue, 24 Mar 2015 13:48:04 -0700 (PDT) Received: from [192.168.10.145] ([31.133.152.120]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LzXTy-1ZW6YC0t0M-014igI for ; Tue, 24 Mar 2015 21:48:02 +0100 Message-ID: <5511CD7F.7000408@gmx.net> Date: Tue, 24 Mar 2015 21:47:59 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jNXuNgvBJHskfSLCjPbraHP9j6EIWQk2t" X-Provags-ID: V03:K0:IIQqIXxzkrPyb35a1p50nP+kGZzLOd98Q08ee46CVn+OvsFICeK /9zKMRHJnix5EMYo2oecduS8SaO4gGN+KTp9u+AFikF6FvRC0z5MXkff7yO71dXhQjlhepL k5SCpGInzpNmjntF/heTZ96DBAKe7Io5WJKarnpsl6ckpqBEY9O8wopFuWsr0zV4s/t94y/ vgo+yFuGjhihLrfxu0eiQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] OAuth IETF#92 Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:48:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jNXuNgvBJHskfSLCjPbraHP9j6EIWQk2t Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here are the meeting minutes: https://www.ietf.org/proceedings/92/minutes/minutes-92-oauth Thanks to Tony for taking notes. Ciao Hannes & Derek --jNXuNgvBJHskfSLCjPbraHP9j6EIWQk2t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVEc1/AAoJEGhJURNOOiAtkcIH/2mwu+yy2zBvO3EUhlXfQYYI ZrTRQwaCtJAgAhmFH+tcBJ0jN4ojuKY/FGtgluT1/YqmsMJyf2yV/L0AXKZTWB4J agbPQcbCR6Yf7/aPjJsLM5q6rlv/uPIkpOoTdRvUoH01rpwP3BcJ5720wZAtGEVm JatYiaOWBPrnS9D/eE4wnWmU5Psd4e5FVyEts2L+pbaryyJs2lCGaOTKDl/qv99q mT6b+x9z8sIKWcThuOs2qp2m4vc7c0ybgycxLdCAr3F6U4foqybjfeRjTKDpL7Uq uSxQpRHaQ8XZETo9942EiRcj/lcadl0fALgZ6AvnQKZda2NpEcWTsxplxX0Y05o= =7U1G -----END PGP SIGNATURE----- --jNXuNgvBJHskfSLCjPbraHP9j6EIWQk2t-- From nobody Tue Mar 24 14:26:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D391A0371; Tue, 24 Mar 2015 14:26:43 -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] autolearn=ham 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 V8u__jUrmYI7; Tue, 24 Mar 2015 14:26:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2041A8ADF; Tue, 24 Mar 2015 14:26:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324212638.18914.99887.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 14:26:38 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-26.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:26:43 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-26.txt Pages : 40 Date : 2015-03-24 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-26 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 Mar 24 14:27:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B451A90E8; Tue, 24 Mar 2015 14:26:57 -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] autolearn=ham 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 oZZZ-TzRO-rc; Tue, 24 Mar 2015 14:26:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3045E1A8AF3; Tue, 24 Mar 2015 14:26:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324212648.27400.12122.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 14:26:48 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:26:57 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-12.txt Pages : 18 Date : 2015-03-24 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 24 16:31:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD94A1A00E7 for ; Tue, 24 Mar 2015 16:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uS8GYQbwU23Q for ; Tue, 24 Mar 2015 16:31:16 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159F01A00CD for ; Tue, 24 Mar 2015 16:31:15 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-c3-5511f3c2ffa3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 24.DB.03493.2C3F1155; Tue, 24 Mar 2015 19:31:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t2ONVEWD029481 for ; Tue, 24 Mar 2015 19:31:14 -0400 Received: from dhcp-b0dd.meeting.ietf.org (dhcp-b0dd.meeting.ietf.org [31.133.176.221]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2ONVCfv005685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Mar 2015 19:31:13 -0400 From: Justin Richer X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_80DD75DD-E305-4961-AD28-73D6EF0EFE78"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Tue, 24 Mar 2015 18:31:11 -0500 Message-Id: <6DA5408F-2E11-45AE-A190-1724958D7960@mit.edu> To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUixG6nonvos2CowdznhhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxofZq9kKLgtXPPi3mrGB8b5AFyMnh4SAicTErsOMELaYxIV7 69m6GLk4hAQWM0nMmfmABcI5xijxaMIWZgjnJZPEz1PrWUBa2ARUJeavvMUE0S4l0fT6GCNI EbPAFEaJxvnz2LsYOTiEBZwlzp4TBKlhAaq/u7uVGcTmFbCSaHvzF6xXREBdYs35n0wQcQOJ uae+MIG0SgjIS/RsSp/AyDcL2dRZSMpAbGYBbYllC18zQ9iaEvu7l7NA2PIS29/OgYpbSiye eQMqbitxq28BVK+dxKNpi1gXMHKsYpRNya3SzU3MzClOTdYtTk7My0st0jXXy80s0UtNKd3E CA5vF5UdjM2HlA4xCnAwKvHwBiwRCBViTSwrrsw9xCjJwaQkynv2g2CoEF9SfkplRmJxRnxR aU5q8SFGFaBdjzasvsAoxZKXn5eqJMK77S1QHW9KYmVValE+TJk0B4uSOO+mH3whQgLpiSWp 2ampBalFMFkZDg4lCd5Tn4AaBYtS01Mr0jJzShDSTBychxglOHiAht8CqeEtLkjMLc5Mh8if YlSUEue9AZIQAElklObB9cLS0itGcaC3hHmPfQSq4gGmNLjuV0CDmYAGn8vnAxlckoiQkmpg ZNxyaeeBW04a37VviTDmL1x1SWWyfBwr28uL8+eve+3AX1sn+i8kZH7kbSXF3cb3L9/c3Jsx v3f9qr29+trxLgxmq3qdOh/Wy0tev8TSIr7Lzm7ixAsJb5vKzvlcLAgL23CxPnLfjz/J06TM plfPXqlxfpJFqcqXmysfXlkQtKFx536vlv/RL5VYijMSDbWYi4oTAT4AVRgmAwAA Archived-At: Subject: [OAUTH-WG] Last Call comments on draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 23:31:18 -0000 --Apple-Mail=_80DD75DD-E305-4961-AD28-73D6EF0EFE78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I believe that this draft is misnamed and therefore somewhat misleading: = it=E2=80=99s fundamentally a method of protected key transmission using = JWT, and not about proof of possession of that key. The proof is in = simply using the key to create a JWT within an application (such as will = be in draft-ietf-oauth-signed-http-request). Proof of possession of a = key does not require the transmission of the key or a direct reference = through the client via a data structure, and I don=E2=80=99t want to = accidentally give the impression that one needs to use a structured = token for proof of possession to work. For instance, in an alternative approach, the AS can issue a random-blob = token to the client along side the key value (as it=E2=80=99s done in = this draft), and the client presents the random-blob token to the RS. = The RS then looks up the information about the random-blob, using a = local lookup or introspection or some other magic, to get the = information that it needs. The client doesn=E2=80=99t need to know = anything about it, as the token itself is opaque to the client. That said, overall the structure and function of the draft is good for = what it actually is. The client remains agnostic about what=E2=80=99s = inside the token itself, as in regular OAuth. It gives semantic = processing for an RS to process messages (of various types) signed by = keys issued alongside these structured tokens. I think this problem could be fixed by renaming the draft and rewriting = the introduction. =E2=80=94 Justin --Apple-Mail=_80DD75DD-E305-4961-AD28-73D6EF0EFE78 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVEfPAAAoJEDPAngkbd+w9PAQH/1CgW7vAneGW4gk6BQae2GUL YurJ9Kj3Lmya+odVxY2or0DRARXz2xI+KL02zv0Z1zBP50W12xFctdjCy7X4ic2N z6ns+JwIcQUfx2AI2KW7/dhyRG0Bys5/CW6WmZYRvv8++ezLATVYW7ZZ04V3Xa+j 8NJ6FQp8vUxzmmD6OlsBhTAvHljGsOj979In/kDMupcO1PuJ7l5GG5fxCRawehBv rB4nqVLfldjV6x/D33lREs5UVuXRtCTYg9IXLiovRYw1y4ppFmCrn0+ITmtuYKVO P7sGqJTZ+CkOswAFFjpCi7Yf7Bpz9AARKsuyXAbbP9LfCd+u/FBVfeBghSvxdNo= =65zK -----END PGP SIGNATURE----- --Apple-Mail=_80DD75DD-E305-4961-AD28-73D6EF0EFE78-- From nobody Tue Mar 24 17:47:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA681A1BBC for ; Tue, 24 Mar 2015 17:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 2xYVlu1TyP6J for ; Tue, 24 Mar 2015 17:47:04 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 AEA0A1A1B85 for ; Tue, 24 Mar 2015 17:47:04 -0700 (PDT) Received: by oiag65 with SMTP id g65so8860905oia.2 for ; Tue, 24 Mar 2015 17:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/317TGMDyL4Jacig8tNlupmWqwCW7ISKuRNHdZQVHjE=; b=cqAo0sNmuFiPCGC66Sxn+Wqaoa3Sccc1im4HH+r/eRv7hjO5yOMi1PPUbycZFslP40 cHRivBTpCzybrEWTnkzMEPlwsB1AAIyMy403/o8SJt0hLdugslVgoZdUZ12QHBY5ue1z vT/sao2dJRMdj4UcHqMx0ZnHyvE+23KLQG2YOwEwzEOtfu2lEY7VoBMLtRyCbTYFTCjw l1Ygi8DNST1CsNhL8Nzw5xN5bKz9qZDIPcUhEuV4MhCqJpo0RyZ3EtjEfJp6uykYcIUL 4lsmE5T5ZqmyvxhQ5FWJbWgtkqgswxYQmg1+Yw8zbzX0g3n1b8ngZvJBaqFAerSy0tzZ kHLA== MIME-Version: 1.0 X-Received: by 10.182.24.133 with SMTP id u5mr5384776obf.27.1427244424216; Tue, 24 Mar 2015 17:47:04 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Tue, 24 Mar 2015 17:47:04 -0700 (PDT) In-Reply-To: <6DA5408F-2E11-45AE-A190-1724958D7960@mit.edu> References: <6DA5408F-2E11-45AE-A190-1724958D7960@mit.edu> Date: Wed, 25 Mar 2015 09:47:04 +0900 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c30864e9c5fa0512123c07 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Last Call comments on draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 00:47:06 -0000 --001a11c30864e9c5fa0512123c07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I tend to agree. This document is describing the format of (subset of) what I have been calling as Registered token in contrast to a bearer token. It is currently covering two types of registered token: - key embedding - key reference embedding There can be other types such as - authorized presenter ID embedding etc. as well, in which case, you would have a top level member "azp" and no "cnf". Perhaps a title change to something like "JWT registered token format" etc. may be a good idea. Cheers, Nat 2015-03-25 8:31 GMT+09:00 Justin Richer : > I believe that this draft is misnamed and therefore somewhat misleading: > it=E2=80=99s fundamentally a method of protected key transmission using J= WT, and > not about proof of possession of that key. The proof is in simply using t= he > key to create a JWT within an application (such as will be in > draft-ietf-oauth-signed-http-request). Proof of possession of a key does > not require the transmission of the key or a direct reference through the > client via a data structure, and I don=E2=80=99t want to accidentally giv= e the > impression that one needs to use a structured token for proof of possessi= on > to work. > > For instance, in an alternative approach, the AS can issue a random-blob > token to the client along side the key value (as it=E2=80=99s done in thi= s draft), > and the client presents the random-blob token to the RS. The RS then look= s > up the information about the random-blob, using a local lookup or > introspection or some other magic, to get the information that it needs. > The client doesn=E2=80=99t need to know anything about it, as the token i= tself is > opaque to the client. > > That said, overall the structure and function of the draft is good for > what it actually is. The client remains agnostic about what=E2=80=99s ins= ide the > token itself, as in regular OAuth. It gives semantic processing for an RS > to process messages (of various types) signed by keys issued alongside > these structured tokens. > > I think this problem could be fixed by renaming the draft and rewriting > the introduction. > > =E2=80=94 Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c30864e9c5fa0512123c07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tend to agree.=C2=A0

This document is= describing the format of (subset of) what I have been calling as Registere= d token in contrast to a bearer token.=C2=A0

It is= currently covering two types of registered token:=C2=A0
- key em= bedding
- key reference embedding

There = can be other types such as
- authorized presenter ID embedding

etc. as well, in which case, you would have a top le= vel member "azp" and no "cnf".=C2=A0

Perhaps a title change to something like "JWT registered token = format" etc. may be a good idea.=C2=A0

Cheers= ,=C2=A0

Nat


2015-03-25 8:31 GMT+09:00 J= ustin Richer <jricher@mit.edu>:
I believe that this draft is misnamed and therefore somewhat misleading= : it=E2=80=99s fundamentally a method of protected key transmission using J= WT, and not about proof of possession of that key. The proof is in simply u= sing the key to create a JWT within an application (such as will be in draf= t-ietf-oauth-signed-http-request). Proof of possession of a key does not re= quire the transmission of the key or a direct reference through the client = via a data structure, and I don=E2=80=99t want to accidentally give the imp= ression that one needs to use a structured token for proof of possession to= work.

For instance, in an alternative approach, the AS can issue a random-blob to= ken to the client along side the key value (as it=E2=80=99s done in this dr= aft), and the client presents the random-blob token to the RS. The RS then = looks up the information about the random-blob, using a local lookup or int= rospection or some other magic, to get the information that it needs. The c= lient doesn=E2=80=99t need to know anything about it, as the token itself i= s opaque to the client.

That said, overall the structure and function of the draft is good for what= it actually is. The client remains agnostic about what=E2=80=99s inside th= e token itself, as in regular OAuth. It gives semantic processing for an RS= to process messages (of various types) signed by keys issued alongside the= se structured tokens.

I think this problem could be fixed by renaming the draft and rewriting the= introduction.

=C2=A0=E2=80=94 Justin

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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--001a11c30864e9c5fa0512123c07-- From nobody Tue Mar 24 21:11:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F7B1ACD8B for ; Tue, 24 Mar 2015 21:11:34 -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, SPF_PASS=-0.001] autolearn=ham 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 vyUlCFA-8Kvi for ; Tue, 24 Mar 2015 21:11:33 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 D31C91ACD8A for ; Tue, 24 Mar 2015 21:11:32 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so10466129obc.2 for ; Tue, 24 Mar 2015 21:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hyVc/DGyGimZX7m5pmOxHmpaKSaooKrWRl9Ob26rwqE=; b=jIRAxxidVxEIhfxOB/itEac4d1YzkYJj9FnXz6+PPKMZOCkALBTL8G2iUPsMBE1F9B qvVWPdIDhcnv21+iBm03P+IYL+8rwEQX/5ayUzBaTl/GFfDal7+qp39hmP0ZqnpbaWNn LCy/7CTmROwkNMD7/b8n5x9Qu12MOXjQzURYmDSxsBEzxCqUcsYRd+ngv3AWrCEy/qQq DRCJriOLXJQDOJD8bmRU+tJRKfS4KoK2B63qkb18/dxsVJkOwuZhd/8SGlPTkulHTBfr XQk2hibzT8wd331CL/9CQh6qj46u7/GBScSz/sYyr4JrhEmZcYvjREZ7iiO0TmmUuNJR R7kA== X-Received: by 10.202.178.134 with SMTP id b128mr5524126oif.80.1427256692361; Tue, 24 Mar 2015 21:11:32 -0700 (PDT) Received: from [172.16.87.239] ([199.227.110.154]) by mx.google.com with ESMTPSA id d142sm1127097oih.21.2015.03.24.21.11.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 21:11:30 -0700 (PDT) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (1.0) From: Nat Sakimura X-Mailer: iPhone Mail (12D508) In-Reply-To: <5511CD7F.7000408@gmx.net> Date: Tue, 24 Mar 2015 23:11:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <63777382-BB73-46AE-9193-C98C91F6E38C@gmail.com> References: <5511CD7F.7000408@gmx.net> To: Hannes Tschofenig Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth IETF#92 Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 04:11:34 -0000 Hi Though I have volunteered for the review of pop-02, I am not going to finish= commenting on pop-02 today =3Dnat via iPhone 2015/03/24 15:47=1B$B!"=1B(BHannes Tschofenig =1B= $B$N%a%C%;!<%8=1B(B: > Here are the meeting minutes: > https://www.ietf.org/proceedings/92/minutes/minutes-92-oauth >=20 > Thanks to Tony for taking notes. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Mar 25 06:37:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AB61A1BC3 for ; Wed, 25 Mar 2015 06:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 flsAv1Bn2dTs for ; Wed, 25 Mar 2015 06:37:53 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 887501A0119 for ; Wed, 25 Mar 2015 06:37:53 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so19311564obc.2 for ; Wed, 25 Mar 2015 06:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zdTH4FPcZq6SiacwEoBDXmGoq8jPs+Qt/zKuPhQjgOU=; b=ATp+jsKsU0bkFIZtAKhSQt17NCcacgjsANZyUrip75Ym7CM6YOPtlRH0yBXqC2xFbJ IiG5Y34brVC8WxaWl5axMz2wa+Mq09VKLDXKmimpks1/YiPNFNTF4qkzhD22DSskVVBw 9pKkPYJepgF/aMAAaIGa9UihlAnbDJOPBcRTBxZUrPtMPtrV+vwCUfSc32Oo0wmBK71x J663VUYYdZviJpI3s5z/dkMkNcMJaqEuN17tWv3FHttGaLeljjsYlLNnoQjhFVKKOj/f d2UP/27NV7beCOFAcnc5Ieg5lFw60bwUoj+9g3PMad8dZqVP6xS+duhvC496RGQc1Ot/ 79Og== MIME-Version: 1.0 X-Received: by 10.182.210.197 with SMTP id mw5mr7707399obc.26.1427290673020; Wed, 25 Mar 2015 06:37:53 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Wed, 25 Mar 2015 06:37:52 -0700 (PDT) Date: Wed, 25 Mar 2015 22:37:52 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=001a11c29be88e880805121d0128 Archived-At: Subject: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 13:37:56 -0000 --001a11c29be88e880805121d0128 Content-Type: text/plain; charset=UTF-8 Dear OAuthers: Here is my belated review comments on draft-ietf-oauth-proof-of-possession-02 Below, [POPA] stands for https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 Abstract ============ It is probably better to spell out that this document is describing the JWT format that can be used for sender constraint (5.2 of [POPA]) and key confirmation (5.3 of [POPA]). This will make it easier for the reader to understand what this document aims at. Accordingly, we should consider the title change to something like: JWT Sender Confirmation Token Syntax OR borrowing from the financial concept which I believe is the origin of the concept of "bearer token", JWT Registered Token Syntax -- here, "Registered" mean that either the sender constraint or key confirmation is registered within or in conjunction with the token. 1. Introduction ============== Consider referencing draft-ietf-oauth-pop-architecture. It will be clearer for the reader then, and the text will be shorter. 2. Terminology - Presenter ======================== Sentence 1 ------------------- Not sure if the first sentence is accurately reflecting the intent. It excludes rogue party presenting the token (and fails) from presenter. If so, it is fine but using more qualified term like "authorized presenter" may make it easier for the reader to parse. Otherwise revise the definition. Sentence 2 ------------------- "issuer or a party different from the issuer" is not constraining anything and meaningless. There are more easier to parse and accurate text coming in the main text, too. Drop. 3. Proof-Of-Posession Representation ============================== Title --------- Perhaps "Sender Representation in JWT" is more reflective of the content. Para 2 ------------- The paragraph describes two ways of sender confirmation: (1) Sender Constraint (2) Key Confirmation It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the terminology. Then, it goes on to describe (1) very briefly, in which it is just spelling out "iss" and "sub". I understand the use of sub in this section comes down from SAML but I feel that some separation between sub and presenter would be nice. For example, when I am presenting the token using an app that I installed on my iPhone, the presenter is that app and not me, while the sub still may be me. The app is the authorized presenter/party (azp) of the token. The JWT may well be about the sub but presented by some software component that should be independently identified. So my proposal is to create a new subsection on (1) for the completeness, which is going to be a new 3.1, and to use a claim like "azp" instead of "sub" to identify the presenter. Less overload would cause less confusion later, IMHO. 3.1 ====== Title -------- Perhaps "Confirmation Key Representation for an Asymmetric Key" is more reflective of the content. 3.2 ======== Title ----------- Perhaps "Confirmation Key Representation for a Symmetric Key" is more reflective of the content. Last Para ----------------- I feel a bit like needing to sniff into the content of jwk to find out what type may not be optimal, though I do not have a concrete proposal a this time. 3.3 ====== Title --------- Perhaps "Confirmation Key Representation by Key ID" is more reflective of the content. Para 1 ----------- There has been some discussion of using thumbprint instead of a blob "kid". This is a valid option. If we are to overload the "kid" member for this purpose, we need to find a way to signal that it is a thumbprint. It may very well be better to define a separate member name then for the thumbprint. The title then changes to "-- by Key ID" to "-- by reference". Also, it is conceivable to use the combination of "kid" and "jku". This aspect is not spelled out here but appears that some magic happens for the key distribution. 3.4 ======== Since "cnf" appears before 3.4, it may be better to bring 3.4 at the front. 5.2.2 ========= Add "azp" and "jkt". o Confirmation Method Value: "azp" o Confirmation Method Description: Client ID of the Authorized Presenter o Change Controller: IESG o Specification Document(s): Section [TBD] of [[ this document ]] o Confirmation Method Value: "jkt" o Confirmation Method Description: JWK Thumbprint of the Confirmation Key o Change Controller: IESG o Specification Document(s): Section [TBD] of [[ this document ]] o Confirmation Method Value: "jku" o Confirmation Method Description: JWK URI of the Confirmation Key o Change Controller: IESG o Specification Document(s): Section [TBD] of [[ this document ]] Privacy Consideration ======================== It is missing privacy consideration. It is not required per se, but since Key Confirmation method with ephemeral key can be less privacy intrusive compared to other sender confirmation method so adding some text around it may be a good idea. Best, -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c29be88e880805121d0128 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear OAuthers:=C2=A0

Here is my b= elated review comments on=C2=A0dr= aft-ietf-oauth-proof-of-possession-02


Abstract
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
It is probably better to spell = out that this document is describing the JWT format that can be used for se= nder constraint (5.2 of [POPA]) and key confirmation (5.3 of [POPA]). This = will make it easier for the reader to understand what this document aims at= .=C2=A0

Accordingly, we should consider the title = change to something like:=C2=A0
JWT Sender Confirmation = Token Syntax=C2=A0
=C2=A0 OR
borrowing from the financi= al concept which I believe is the origin of the concept of "bearer tok= en",=C2=A0
JWT Registered Token Syntax
-- here, &q= uot;Registered" mean that either the sender constraint or key confirma= tion is registered within or in conjunction with the token.=C2=A0

1. Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Consider referencing draft-ietf-oauth-pop-architecture.= =C2=A0
It will be clearer for the reader then, and the text will = be shorter.=C2=A0

2. Terminology - Presenter
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Sentence 1
-------------------
Not sure i= f the first sentence is accurately reflecting the intent.=C2=A0
I= t excludes rogue party presenting the token (and fails) from presenter.=C2= =A0
If so, it is fine but using more qualified term like "au= thorized presenter" may make it easier=C2=A0
for the reader = to parse.=C2=A0

Otherwise revise the definition.= =C2=A0

Sentence 2
-------------------
"issuer or a party different from the issuer" is not cons= training anything and meaningless.=C2=A0
There are more easier to= parse and accurate text coming in the main text, too.=C2=A0
Drop= .=C2=A0

3. Proof-Of-Posession Representation
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Title
---------
Perhaps= "Sender Representation in JWT" is more reflective of the content= .=C2=A0

Para 2
-------------
The paragraph describes two ways of sender confirmation:=C2=A0
(1) Sender Constraint
(2) Key Confirmation
It should r= efer to 5.2 and 5.3 of [POPA] for it, as well as align the terminology.=C2= =A0

Then, it goes on to describe (1) very briefly,= in which it is just spelling out "iss" and "sub".=C2= =A0

I understand the use of sub in this section comes d= own from SAML but I feel that some separation between sub and presenter wou= ld be nice.

For example, when I am presenting the token using an ap= p that I installed on my iPhone, the presenter is that app and not me, whil= e the sub still may be me. The app is the authorized presenter/party (azp) = of the token.=C2=A0The JWT may well be about the sub but presented by some = software component that should be independently identified. =C2=A0

= So my proposal is to create a new subsection on (1) for the completeness, w= hich is going to be a new 3.1, and to use a claim like "azp" inst= ead of "sub" to identify the presenter. Less overload would cause= less confusion later, IMHO.

3.1
=3D=3D= =3D=3D=3D=3D
Title
--------
Perhaps "Con= firmation Key Representation for an Asymmetric Key" is more reflective= of the content.=C2=A0

3.2
=3D=3D=3D=3D= =3D=3D=3D=3D
Title
-----------
Perhaps "= Confirmation Key Representation for a Symmetric Key" is more reflectiv= e of the content.=C2=A0

Last Para
--= ---------------
I feel a bit like needing to sniff into the conte= nt of jwk to find out what type may not be optimal, though I do not have a = concrete proposal a this time.=C2=A0

3.3
=3D=3D=3D=3D=3D=3D
Title
---------
Perhaps &= quot;Confirmation Key Representation by Key ID" is more reflective of = the content.=C2=A0

Para 1
----------= -
There has been some discussion of using thumbprint instead of a= blob "kid".=C2=A0
This is a valid option. If we are to= overload the "kid" member for this purpose, we need to find a wa= y to signal that it is a thumbprint.=C2=A0
It may very well be be= tter to define a separate member name then for the thumbprint. The title th= en changes to "-- by Key ID" to "-- by reference".=C2= =A0

Also, it is conceivable to use the combination= of "kid" and "jku". This aspect is not spelled out her= e but appears that some magic happens for the key distribution.=C2=A0
=

3.4=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D
=
Since "cnf" appears before 3.4, it may be better to bring 3.= 4 at the front.=C2=A0

5.2.2
=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Add "azp" and "jkt".=C2= =A0

o =C2=A0Confirmation Method Value: "azp"<= br>o =C2=A0Confirmation Method Description: Client ID of the Authorized Pre= senter
o =C2=A0Change Controller: IESG
o =C2=A0Specification Document= (s): Section [TBD] of [[ this document ]]


o =C2=A0Confirmation M= ethod Value: "jkt"
o =C2=A0Confirmation Method Description: JW= K Thumbprint of the Confirmation Key
o =C2=A0Change Controller: IESG
= o =C2=A0Specification Document(s): Section [TBD] of [[ this document ]]
=

o =C2=A0Confirmation Method Value: "jku"
o =C2=A0Confi= rmation Method Description: JWK URI of the Confirmation Key
o =C2=A0Chan= ge Controller: IESG
o =C2=A0Specification Document(s): Section [TBD] of = [[ this document ]]

Privacy Consideration
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
It is missing privacy consideration. It is not required per se, but si= nce Key Confirmation method with ephemeral key can be less privacy intrusiv= e compared to other sender confirmation method so adding some text around i= t may be a good idea.=C2=A0

Best,=C2=A0
= --
Nat Sakimura (=3Dnat)
Chairman, O= penID Foundation
= http://nat.sakimura.org/
@_nat_en
--001a11c29be88e880805121d0128-- From nobody Wed Mar 25 07:37:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20031A1B77 for ; Wed, 25 Mar 2015 07:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 XEnOUY5qyMFs for ; Wed, 25 Mar 2015 07:37:42 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC94D1A1BED for ; Wed, 25 Mar 2015 07:37:31 -0700 (PDT) Received: from mail-ig0-f179.google.com ([209.85.213.179]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKVRLIKxeshCKWgqpyPOXgmTc90HNSP33C@postini.com; Wed, 25 Mar 2015 07:37:32 PDT Received: by igcau2 with SMTP id au2so102812772igc.0 for ; Wed, 25 Mar 2015 07:37:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=igTo5tBlRcWYRo6aTQTc5ebMZT0qPCTJvcFAzsVu1Fw=; b=K/gN9GfTaGR249cDPNzJJluZqhcwO1kfon2GiiAXCNtFAc4HWIscaxdzExOcUZz8lO E28th7TMxFgh2ZpwLUtcbMopzZRh8xZWKRiQDyhrUcae63MY3KFY2nzZCmnmvozwEgzx xJdwRI8o+0G8SpvKuXvMhWcW34Jd2bzeqKTr4N4K6kv220z1LLbm2LrDAVTehKwdjDOa 0ztEuOSqNNpJSS45IYPUoHPiSaPajzzQn7nY1Kjkc0S6GrzqsL15bzJbkS1UI3wFi3PO TKItTPWnRU+s6HWGAeHOrN9GU/AmeQfnf842gEDTIQXdbqbuhNixoHBIWryMPj3RxNF7 oFJg== X-Gm-Message-State: ALoCoQmYc/jjYyueOGsTygOQKSszDR9K5jhEgJXqfn9yh+Dy303GcLQRq4fpx08vQdQdZtoSK6+8TzXVM2G9c9EBawF3qvAg95qmANElUOJg+MtDE53dBcxirzukia7stBJQ08meOMUt X-Received: by 10.43.29.208 with SMTP id rz16mr33120266icb.89.1427294251081; Wed, 25 Mar 2015 07:37:31 -0700 (PDT) X-Received: by 10.43.29.208 with SMTP id rz16mr33120252icb.89.1427294250961; Wed, 25 Mar 2015 07:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Wed, 25 Mar 2015 07:37:00 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 25 Mar 2015 09:37:00 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=bcaec5186582d1a2af05121dd678 Archived-At: Subject: Re: [OAUTH-WG] trouble reading the start of sec 3 proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 14:37:43 -0000 --bcaec5186582d1a2af05121dd678 Content-Type: text/plain; charset=UTF-8 There's similar wording in sec 3.3 too that seems to suggest that the presenter is the one that makes the claim. I think the presenter confirms the claim when it presents. It's the issuer that makes/asserts/declares the claim. No? "In this case, the presenter of a JWT declares that it possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter by including a "cnf" (confirmation) claim in the JWT whose value is a JSON object, with the JSON object containing a "kid" (key ID) member identifying the key." On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell wrote: > My brain hurt trying to parse the first sentence/paragraph from section 3 > : > > > "The presenter of a JWT declares that it possesses a particular key > and that the recipient can cryptographically confirm proof-of- > possession of the key by the presenter by including a "cnf" > (confirmation) claim in the JWT whose value is a JSON object, with > the JSON object containing a "jwk" (JSON Web Key) or "kid" (key ID) > member identifying the key." > > The issuer includes the "cnf" claim and makes the declaration not the > presenter. Sure, the presenter may be the issuer but that's a special case. > > Isn't it more accurate to say that it is the issuer who declares that the > presenter can confirm itself by some cryptographic proof-of-possession of > the key identified by the "cnf" claim? Or something more like that... > > > > > --bcaec5186582d1a2af05121dd678 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's similar wording in sec 3= .3 too that seems to suggest that the presenter is the one that makes t= he claim.

I think the presenter confirms the claim when it pr= esents. It's the issuer that makes/asserts/declares the claim. No?=C2= =A0 

  "In
   this case, the presenter of a JWT declares that it possesses a
   particular key and that the recipient can cryptographically confirm
   proof-of-possession of the key by the presenter by including a "cnf=
"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "kid" (key ID) member identifying=
 the
   key."

On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell &= lt;bcampbel= l@pingidentity.com> wrote:
=
My brain hurt trying to parse the first sentence= /paragraph from section 3: 
  =
 "The presenter of a JWT declares that it possesses a particular key
   and that the recipient can cryptographically confirm proof-of-
   possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "jwk" (JSON Web Key) or "kid=
" (key ID)
   member identifying the key."
The issuer includes the= "cnf" claim and makes the declaration not the presenter. Sure, t= he presenter may be the issuer but that's a special case.

= Isn't it more accurate to say that it is the issuer who declares that t= he presenter can confirm itself by some cryptographic proof-of-possession o= f the key identified by the "cnf" claim? Or something more like t= hat...


--bcaec5186582d1a2af05121dd678-- From nobody Wed Mar 25 08:31:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1671A87BB for ; Wed, 25 Mar 2015 08:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ebLP6oHvth5t for ; Wed, 25 Mar 2015 08:31:34 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 11C711B29FF for ; Wed, 25 Mar 2015 08:31:31 -0700 (PDT) Received: by oiag65 with SMTP id g65so24449520oia.2 for ; Wed, 25 Mar 2015 08:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AVgds5IvuLP6g7KOqFzB8qVZ3iv9Mm+8TOj9Yjtebec=; b=k7aKvKlHXDy8995SU45FDKZhFuh7iAD6VqyBb4SgiGPH7tAzCGEE1z2IoL1NuqBuuN wXnyunUPozkUGcp3s1swduuEIkQI7DttErjSjLI9ylLrUXjPG9Oc4dsJgYIabc81N3xM 6G4XKIu6KIZwlIwD0LakxpO82Oa5C2k9uTjBUcCWxau0K7/1kH3Ae56n9jrWJPr2YNiD DiCGGJ0HhhYrxJkoWDUwNRSpqKeykFbCk/PL3WUhbXvDuWY8WFp5+0hJo7WPYSPd4Rzj apknUSQ+Q5LEKILO7FYkltPepVvi1vVFauUgjwPbF6RskbQADQpxdMED8+gfpDZMSBb/ 4XFQ== MIME-Version: 1.0 X-Received: by 10.182.242.106 with SMTP id wp10mr7900152obc.14.1427297490549; Wed, 25 Mar 2015 08:31:30 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Wed, 25 Mar 2015 08:31:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2015 00:31:30 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=e89a8ff2521ae9c28605121e9762 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] trouble reading the start of sec 3 proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:31:36 -0000 --e89a8ff2521ae9c28605121e9762 Content-Type: text/plain; charset=UTF-8 My take is that the presenter presents the token with cnf claim and some kind of proof of possession of the material that cnf claim refers to. It is the recipient that "confirms" or "verifies" the claim made by the authorized presenter is correct. 2015-03-25 23:37 GMT+09:00 Brian Campbell : > There's similar wording in sec 3.3 > > too that seems to suggest that the presenter is the one that makes the > claim. > > I think the presenter confirms the claim when it presents. It's the issuer > that makes/asserts/declares the claim. No? > > "In > this case, the presenter of a JWT declares that it possesses a > particular key and that the recipient can cryptographically confirm > proof-of-possession of the key by the presenter by including a "cnf" > (confirmation) claim in the JWT whose value is a JSON object, with > the JSON object containing a "kid" (key ID) member identifying the > key." > > > On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> My brain hurt trying to parse the first sentence/paragraph from section 3 >> : >> >> >> "The presenter of a JWT declares that it possesses a particular key >> and that the recipient can cryptographically confirm proof-of- >> possession of the key by the presenter by including a "cnf" >> (confirmation) claim in the JWT whose value is a JSON object, with >> the JSON object containing a "jwk" (JSON Web Key) or "kid" (key ID) >> member identifying the key." >> >> The issuer includes the "cnf" claim and makes the declaration not the >> presenter. Sure, the presenter may be the issuer but that's a special case. >> >> Isn't it more accurate to say that it is the issuer who declares that the >> presenter can confirm itself by some cryptographic proof-of-possession of >> the key identified by the "cnf" claim? Or something more like that... >> >> >> >> >> > > _______________________________________________ > 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 --e89a8ff2521ae9c28605121e9762 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My take is that the presenter presents the token with cnf = claim and some kind of proof of possession of the material that cnf claim r= efers to. It is the recipient that "confirms" or "verifies&q= uot; the claim made by the authorized presenter is correct.=C2=A0

2015-03-25 23:37 GMT+= 09:00 Brian Campbell <bcampbell@pingidentity.com>:<= br>
There's similar= wording in sec 3.3 too that seems t= o suggest that the presenter is the one that makes the claim.

I think the presenter confirms the claim when it presents. It's the is= suer that makes/asserts/declares the claim. No?=C2=A0 

  "=
In
   this case, the presenter of a JWT declares that it possesses a
   particular key and that the recipient can cryptographically confirm
   proof-of-possession of the key by the presenter by including a "cnf=
"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "kid" (key ID) member identifying=
 the
   key."

On Sun, Mar 22, 2015 at 8:4= 2 PM, Brian Campbell <bcampbell@pingidentity.com> w= rote:
My brain= hurt trying to parse the first sentence/paragraph from section 3: 
   "The presenter of a JWT decla=
res that it possesses a particular key
   and that the recipient can cryptographically confirm proof-of-
   possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "jwk" (JSON Web Key) or "kid=
" (key ID)
   member identifying the key."
The issuer includes the= "cnf" claim and makes the declaration not the presenter. Sure, t= he presenter may be the issuer but that's a special case.

= Isn't it more accurate to say that it is the issuer who declares that t= he presenter can confirm itself by some cryptographic proof-of-possession o= f the key identified by the "cnf" claim? Or something more like t= hat...



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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--e89a8ff2521ae9c28605121e9762-- From nobody Wed Mar 25 08:35:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4CA1B2A46 for ; Wed, 25 Mar 2015 08:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VTPDWKLMI3Uu for ; Wed, 25 Mar 2015 08:35:07 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2D31B2A49 for ; Wed, 25 Mar 2015 08:34:59 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-3f-5512d5a181d5 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id FF.AE.03389.1A5D2155; Wed, 25 Mar 2015 11:34:57 -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 t2PFYvGY001755; Wed, 25 Mar 2015 11:34:57 -0400 Received: from dhcp-b0dd.meeting.ietf.org (dhcp-b0dd.meeting.ietf.org [31.133.176.221]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2PFYo8J002113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2015 11:34:56 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EC406EAA-43DF-4BAA-8D03-688BCD835D63"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: Date: Wed, 25 Mar 2015 10:34:48 -0500 Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsUixCmqrbvwqlCowcQpJhar/99ktDj59hWb A5PHkiU/mTzuHr3IEsAUxWWTkpqTWZZapG+XwJXx4vUN1oLt9hWfZy1hbmDcYdbFyMkhIWAi sW7re2YIW0ziwr31bF2MXBxCAouZJA7POsIE4WxklGj82ADlXGGSWP7wGAtIi7BAoETjnKtg Nq+AgcTcU1/AipgFpjBK7J9ymBFirpRE0+tjYDabgKrE9DUtQEUcHJxAzfdX2oCYLEDh7dsT QExmAXWJ9pMuEBOtJF7fnswEYgsJTGWUOHo+FMQWEdCXuP10DjtIuYSAvETPpvQJjIKzkNww C9kNIAlmgSSJ7V1f2SBsbYllC18zQ9iaEvu7l7NgimtIdH6byAphy0tsfzsHKm4psXjmDah6 W4lbfQuYIGw7iUfTFrEuYORexSibklulm5uYmVOcmqxbnJyYl5dapGuil5tZopeaUrqJERx/ kvw7GL8dVDrEKMDBqMTD+0NCKFSINbGsuDL3EKMkB5OSKO/+M0AhvqT8lMqMxOKM+KLSnNTi Q4wqQLsebVh9gVGKJS8/L1VJhHfnJqA63pTEyqrUonyYMmkOFiVx3k0/+EKEBNITS1KzU1ML UotgsjIcHEoSvCuvADUKFqWmp1akZeaUIKSZODgPMUpw8AANPwJSw1tckJhbnJkOkT/FqCgl zvsLJCEAksgozYPrhaXNV4ziQG8J8zqDVPEAUy5c9yugwUxAg8/l84EMLklESEk1MDppTFuj VrD49keRH1WRu28drlnSUFMosLYqtebC7YbJxwJENk39oprxi1f16/wH+9acjZ+U+EBLLoZJ wuXfbEPHWVcSNfc9mXH+PUuycMT+AybfW7y9Jk5k2ze/5nzBW4ktl+88PequWFZR37hQeZrQ /S7fLZ1TmCK+eV4OXNqvu2FV9qeMw3eUWIozEg21mIuKEwFCuIjzdgMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] trouble reading the start of sec 3 proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:35:14 -0000 --Apple-Mail=_EC406EAA-43DF-4BAA-8D03-688BCD835D63 Content-Type: multipart/alternative; boundary="Apple-Mail=_9363E9DD-C16A-4E16-B995-3879B6E09F51" --Apple-Mail=_9363E9DD-C16A-4E16-B995-3879B6E09F51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agree that this language isn=E2=80=99t clear. The presenter doesn=E2=80=99= t confirm the claim either, the presenter never even looks for it = (unless the presenter is the issuer, which is a special and hopefully = rare case). That=E2=80=99s why the key is delivered to the presenter in = parallel with the token. It=E2=80=99s the RS that confirms the claim (in = OAuth PoP), or whoever=E2=80=99s processing the key-protected call = downstream (in something that isn=E2=80=99t OAuth). =E2=80=94 Justin > On Mar 25, 2015, at 9:37 AM, Brian Campbell = wrote: >=20 > There's similar wording in sec 3.3 = too that seems to suggest that the presenter is the one that = makes the claim. >=20 > I think the presenter confirms the claim when it presents. It's the = issuer that makes/asserts/declares the claim. No? >=20 > "In > this case, the presenter of a JWT declares that it possesses a > particular key and that the recipient can cryptographically confirm > proof-of-possession of the key by the presenter by including a = "cnf" > (confirmation) claim in the JWT whose value is a JSON object, with > the JSON object containing a "kid" (key ID) member identifying the > key." >=20 > On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell = > wrote: > My brain hurt trying to parse the first sentence/paragraph from = section 3 = : > "The presenter of a JWT declares that it possesses a particular key > and that the recipient can cryptographically confirm proof-of- > possession of the key by the presenter by including a "cnf" > (confirmation) claim in the JWT whose value is a JSON object, with > the JSON object containing a "jwk" (JSON Web Key) or "kid" (key ID) > member identifying the key." > The issuer includes the "cnf" claim and makes the declaration not the = presenter. Sure, the presenter may be the issuer but that's a special = case. >=20 > Isn't it more accurate to say that it is the issuer who declares that = the presenter can confirm itself by some cryptographic = proof-of-possession of the key identified by the "cnf" claim? Or = something more like that... >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9363E9DD-C16A-4E16-B995-3879B6E09F51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agree that this language isn=E2=80=99t clear. The presenter = doesn=E2=80=99t confirm the claim either, the presenter never even looks = for it (unless the presenter is the issuer, which is a special and = hopefully rare case). That=E2=80=99s why the key is delivered to the = presenter in parallel with the token. It=E2=80=99s the RS that confirms = the claim (in OAuth PoP), or whoever=E2=80=99s processing the = key-protected call downstream (in something that isn=E2=80=99t = OAuth).

 =E2=80=94= Justin

On Mar 25, 2015, at 9:37 AM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

There's similar = wording in sec 3.3 too that seems to suggest that the = presenter is the one that makes the claim.

I think the presenter confirms the claim when it = presents. It's the issuer that makes/asserts/declares the claim. = No?  

  "In
   this case, the presenter of a JWT declares that it possesses a
   particular key and that the recipient can cryptographically confirm
   proof-of-possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "kid" (key ID) member identifying the
   key."

On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:
My brain hurt trying to parse = the first sentence/paragraph from section 3: 
   "The presenter of a JWT declares that it =
possesses a particular key
   and that the recipient can cryptographically confirm proof-of-
   possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "jwk" (JSON Web Key) or "kid" (key ID)
   member identifying the key."
The issuer = includes the "cnf" claim and makes the declaration not the presenter. = Sure, the presenter may be the issuer but that's a special case.

Isn't it more accurate to say that it is = the issuer who declares that the presenter can confirm itself by some = cryptographic proof-of-possession of the key identified by the "cnf" = claim? Or something more like that...



 =


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

= --Apple-Mail=_9363E9DD-C16A-4E16-B995-3879B6E09F51-- --Apple-Mail=_EC406EAA-43DF-4BAA-8D03-688BCD835D63 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVEtWZAAoJEDPAngkbd+w99NMH/28raZVvI9BsWnh619vsC7cf 8bzsBBUdUvpO4q6o0PluNzD9EcZNDT6UMKq6jhK7JLGrhBeCyfow0PYwLUIbN5lo QxEDlwsOgkILqaKuWkmGE66SyEy1vYu6mQCkfCRiiHERrod+Dob63kKy2qFF6nBC XuHgeofmm7FM1nd/GEPhAtuli3enCu91r4mM5esfeQpX2HDM2RnXKbfboiPye5+9 2A59iEelV2yscLAZlkI3fXwHdI+ftgKTkpmxNkrJ/+Otbg/U6y+GhsaageIYbsrk g86b1PY3YgiYev4K0mkfNNeqbJjJnSCwxQBzI/tIHPysiz7yGrngozcN93EopqA= =jfOp -----END PGP SIGNATURE----- --Apple-Mail=_EC406EAA-43DF-4BAA-8D03-688BCD835D63-- From nobody Wed Mar 25 08:42:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2F1B2A62 for ; Wed, 25 Mar 2015 08:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 LQwzQZWcgMMi for ; Wed, 25 Mar 2015 08:42:43 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37821A895D for ; Wed, 25 Mar 2015 08:42:42 -0700 (PDT) Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKVRLXbRkr0L1hbzahTIw/s4cYBvi6BYif@postini.com; Wed, 25 Mar 2015 08:42:42 PDT Received: by igbud6 with SMTP id ud6so104898003igb.1 for ; Wed, 25 Mar 2015 08:42:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=B5mhur16pshv+DyeJK+qhwe8BcqiUATpa1ldaiasVGE=; b=H+zqnayMDvYLQdCSkUev2Um+2+Hak1IOzisV8UpNjP94Dq6I0XKD9SmwXmyqjnxZQd MjZqPILPhOwY3fUlnZIk1hDkcJOyUOTKDN6Tv8gLOZsYzfW42HkSTuOJ2QjOqviV/9Zx RLUPTS4XQYElpIX+a/dxqG8Gp++ITmbzbr5KCSBVaSlE3M1NLU8GfqN1xebzxwZqCy9H WZ3SeMDhT4tAkmybgFH3954Yw6hpfXWF/25w+4sYhqaE7FFn79ILyi4ssK3Vmxa0k+zG MSVqVh0ozer2ijyQUL0Xn/76tdQFdTi2o8znY+qNzM2ksYjDvq3NnTUtlQskHHMjEcAN grxQ== X-Gm-Message-State: ALoCoQltOjrdZFdGwHLU6ErOlD78W9fWK6IBhbQgXaEqI2c+yiJgzNvTHP5ubcNNJmhh5LpOxjWYDoWHeh7ZpB1LR/9yx5jyDwnciheqTQ0JZ94QmkRp2/6V8C0RrF9m0ZvUFfS/zKmu X-Received: by 10.107.35.70 with SMTP id j67mr14490312ioj.51.1427298156874; Wed, 25 Mar 2015 08:42:36 -0700 (PDT) X-Received: by 10.107.35.70 with SMTP id j67mr14490303ioj.51.1427298156761; Wed, 25 Mar 2015 08:42:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Wed, 25 Mar 2015 08:42:06 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 25 Mar 2015 10:42:06 -0500 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a1140dcf29f717505121ebf31 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] trouble reading the start of sec 3 proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:42:48 -0000 --001a1140dcf29f717505121ebf31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, sorry, I misspoke (this stuff isn't easy). The presenter doesn't confirm. The presenter presents the token along with something that proves possession, which allows the recipient to confirm. My original grip with both texts is that they seem to suggests that the presenter makes the declaration in the token, which isn't true except for the special case of issuer=3Dpresenter. In trying to clarify that, I made a different mistake. I'm sure the draft authors will have no problem stating it clearly, concisely and accurately though :) On Wed, Mar 25, 2015 at 10:34 AM, Justin Richer wrote: > Agree that this language isn=E2=80=99t clear. The presenter doesn=E2=80= =99t confirm the > claim either, the presenter never even looks for it (unless the presenter > is the issuer, which is a special and hopefully rare case). That=E2=80=99= s why the > key is delivered to the presenter in parallel with the token. It=E2=80=99= s the RS > that confirms the claim (in OAuth PoP), or whoever=E2=80=99s processing t= he > key-protected call downstream (in something that isn=E2=80=99t OAuth). > > =E2=80=94 Justin > > On Mar 25, 2015, at 9:37 AM, Brian Campbell > wrote: > > There's similar wording in sec 3.3 > > too that seems to suggest that the presenter is the one that makes the > claim. > > I think the presenter confirms the claim when it presents. It's the issue= r > that makes/asserts/declares the claim. No? > > "In > this case, the presenter of a JWT declares that it possesses a > particular key and that the recipient can cryptographically confirm > proof-of-possession of the key by the presenter by including a "cnf" > (confirmation) claim in the JWT whose value is a JSON object, with > the JSON object containing a "kid" (key ID) member identifying the > key." > > > On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> My brain hurt trying to parse the first sentence/paragraph from section = 3 >> : >> >> >> "The presenter of a JWT declares that it possesses a particular key >> and that the recipient can cryptographically confirm proof-of- >> possession of the key by the presenter by including a "cnf" >> (confirmation) claim in the JWT whose value is a JSON object, with >> the JSON object containing a "jwk" (JSON Web Key) or "kid" (key ID) >> member identifying the key." >> >> The issuer includes the "cnf" claim and makes the declaration not the >> presenter. Sure, the presenter may be the issuer but that's a special ca= se. >> >> Isn't it more accurate to say that it is the issuer who declares that th= e >> presenter can confirm itself by some cryptographic proof-of-possession o= f >> the key identified by the "cnf" claim? Or something more like that... >> >> >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a1140dcf29f717505121ebf31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, sorry, I misspoke (this stuff isn't easy). The p= resenter doesn't confirm. The presenter presents the token along with s= omething that proves possession, which allows the recipient to confirm. My = original grip with both texts is that they seem to suggests that the presen= ter makes the declaration in the token, which isn't true except for the= special case of issuer=3Dpresenter. In trying to clarify that, I made a di= fferent mistake. I'm sure the draft authors will have no problem statin= g it clearly, concisely and accurately though :)=C2=A0

On Wed, Mar 25, 2015 at 10:34 A= M, Justin Richer <jricher@mit.edu> wrote:
Agree that this language = isn=E2=80=99t clear. The presenter doesn=E2=80=99t confirm the claim either= , the presenter never even looks for it (unless the presenter is the issuer= , which is a special and hopefully rare case). That=E2=80=99s why the key i= s delivered to the presenter in parallel with the token. It=E2=80=99s the R= S that confirms the claim (in OAuth PoP), or whoever=E2=80=99s processing t= he key-protected call downstream (in something that isn=E2=80=99t OAuth).

=C2=A0=E2= =80=94 Justin

On Mar 25, 2015, at 9:37 AM, Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

There's similar wording in sec 3.3 too that seems to suggest that the presenter i= s the one that makes the claim.

I think the presenter confirm= s the claim when it presents. It's the issuer that makes/asserts/declar= es the claim. No?=C2=A0 

  "In
   this case, the presenter of a JWT declares that it possesses a
   particular key and that the recipient can cryptographically confirm
   proof-of-possession of the key by the presenter by including a "cnf=
"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "kid" (key ID) member identifying=
 the
   key."

On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell &= lt;bcampbel= l@pingidentity.com> wrote:
=
My brain hurt trying to parse the first sentence= /paragraph from section 3: 
  =
 "The presenter of a JWT declares that it possesses a particular key
   and that the recipient can cryptographically confirm proof-of-
   possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "jwk" (JSON Web Key) or "kid=
" (key ID)
   member identifying the key."
The issuer includes the= "cnf" claim and makes the declaration not the presenter. Sure, t= he presenter may be the issuer but that's a special case.

= Isn't it more accurate to say that it is the issuer who declares that t= he presenter can confirm itself by some cryptographic proof-of-possession o= f the key identified by the "cnf" claim? Or something more like t= hat...


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth


--001a1140dcf29f717505121ebf31-- From nobody Wed Mar 25 08:48:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59CC1A884E for ; Wed, 25 Mar 2015 08:48:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 IXjmdPUwQkr9 for ; Wed, 25 Mar 2015 08:48:08 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 AFE001A884D for ; Wed, 25 Mar 2015 08:48:07 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so29851542wib.0 for ; Wed, 25 Mar 2015 08:48:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hdDuO2cjNCAVHxbmGqbJ4u0lyB/DP/pjZb7sSyDHcLg=; b=RFLDWTRs42JSs8/e7GkxTDg1CpFJJJHhN3h6qeOV5SSMx+a5xCYi3ZhRrcmTMzskKV FEdFs8pHeNzGOI/EcbOewFF7eLsesIE5dIG/5jxf0q5hZEMhywu9YMFDg5t4g0ADUWlu IIPpLkzAnPW444LeK1bvGbtl1YYm0DUnh/Br2bI4Hk2m3mhzwd4bRvfaKWyoLoeolLxJ mFgUqBRW/AeTsgJPywdjcv+b2JpwN7LubHLDb6KsFFvkjkJQw+sNw5E1bJNAWk5Ya3eD p4tIzFBFm7imYqJt+DHcgBKOw/lpJAGztKZvcPm7gIZ/iJw5/1a4M5uBOIqLAp1AhT0V W7Cw== X-Gm-Message-State: ALoCoQl9MuHdce9NC+CEPNb3QQq7SBjxsmVvBUwGSaKLDZSou60QrTpRvkZnDRAz4mVLju+/KUxQ X-Received: by 10.194.19.166 with SMTP id g6mr19542905wje.150.1427298486195; Wed, 25 Mar 2015 08:48:06 -0700 (PDT) Received: from ?IPv6:2001:67c:370:144:dad:f918:c78:f070? ([2001:67c:370:144:dad:f918:c78:f070]) by mx.google.com with ESMTPSA id wc10sm21190690wic.21.2015.03.25.08.48.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 08:48:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_04C3EC02-57E1-46DF-ADD6-F153029B97D8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Wed, 25 Mar 2015 10:48:01 -0500 Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] trouble reading the start of sec 3 proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:48:10 -0000 --Apple-Mail=_04C3EC02-57E1-46DF-ADD6-F153029B97D8 Content-Type: multipart/alternative; boundary="Apple-Mail=_13F152D1-9FFF-41B7-83C4-41F16B82817D" --Apple-Mail=_13F152D1-9FFF-41B7-83C4-41F16B82817D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sure no problem:) > On Mar 25, 2015, at 10:42 AM, Brian Campbell = wrote: >=20 > Yeah, sorry, I misspoke (this stuff isn't easy). The presenter doesn't = confirm. The presenter presents the token along with something that = proves possession, which allows the recipient to confirm. My original = grip with both texts is that they seem to suggests that the presenter = makes the declaration in the token, which isn't true except for the = special case of issuer=3Dpresenter. In trying to clarify that, I made a = different mistake. I'm sure the draft authors will have no problem = stating it clearly, concisely and accurately though :)=20 >=20 > On Wed, Mar 25, 2015 at 10:34 AM, Justin Richer > wrote: > Agree that this language isn=E2=80=99t clear. The presenter doesn=E2=80=99= t confirm the claim either, the presenter never even looks for it = (unless the presenter is the issuer, which is a special and hopefully = rare case). That=E2=80=99s why the key is delivered to the presenter in = parallel with the token. It=E2=80=99s the RS that confirms the claim (in = OAuth PoP), or whoever=E2=80=99s processing the key-protected call = downstream (in something that isn=E2=80=99t OAuth). >=20 > =E2=80=94 Justin >=20 >> On Mar 25, 2015, at 9:37 AM, Brian Campbell = > wrote: >>=20 >> There's similar wording in sec 3.3 = too that seems to suggest that the presenter is the one that = makes the claim.=20 >>=20 >> I think the presenter confirms the claim when it presents. It's the = issuer that makes/asserts/declares the claim. No? =20 >>=20 >> "In >> this case, the presenter of a JWT declares that it possesses a >> particular key and that the recipient can cryptographically = confirm >> proof-of-possession of the key by the presenter by including a = "cnf" >> (confirmation) claim in the JWT whose value is a JSON object, with >> the JSON object containing a "kid" (key ID) member identifying the >> key." >>=20 >> On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell = > wrote: >> My brain hurt trying to parse the first sentence/paragraph from = section 3 = :=20 >> "The presenter of a JWT declares that it possesses a particular = key >> and that the recipient can cryptographically confirm proof-of- >> possession of the key by the presenter by including a "cnf" >> (confirmation) claim in the JWT whose value is a JSON object, with >> the JSON object containing a "jwk" (JSON Web Key) or "kid" (key = ID) >> member identifying the key." >> The issuer includes the "cnf" claim and makes the declaration not the = presenter. Sure, the presenter may be the issuer but that's a special = case. >>=20 >> Isn't it more accurate to say that it is the issuer who declares that = the presenter can confirm itself by some cryptographic = proof-of-possession of the key identified by the "cnf" claim? Or = something more like that... >>=20 >>=20 >>=20 >> =20 >>=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=_13F152D1-9FFF-41B7-83C4-41F16B82817D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sure no problem:)

On = Mar 25, 2015, at 10:42 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Yeah, sorry, I misspoke (this stuff isn't easy). The = presenter doesn't confirm. The presenter presents the token along with = something that proves possession, which allows the recipient to confirm. = My original grip with both texts is that they seem to suggests that the = presenter makes the declaration in the token, which isn't true except = for the special case of issuer=3Dpresenter. In trying to clarify that, I = made a different mistake. I'm sure the draft authors will have no = problem stating it clearly, concisely and accurately though :)  =

On Wed, Mar 25, 2015 at 10:34 AM, Justin Richer = <jricher@mit.edu> wrote:
Agree that this language = isn=E2=80=99t clear. The presenter doesn=E2=80=99t confirm the claim = either, the presenter never even looks for it (unless the presenter is = the issuer, which is a special and hopefully rare case). That=E2=80=99s = why the key is delivered to the presenter in parallel with the token. = It=E2=80=99s the RS that confirms the claim (in OAuth PoP), or = whoever=E2=80=99s processing the key-protected call downstream (in = something that isn=E2=80=99t OAuth).

 =E2=80=94 Justin

On Mar 25, 2015, at 9:37 = AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

There's similar wording in sec 3.3 too that seems = to suggest that the presenter is the one that makes the claim.

I think the presenter confirms the claim = when it presents. It's the issuer that makes/asserts/declares the claim. = No?  

  "In
   this case, the presenter of a JWT declares that it possesses a
   particular key and that the recipient can cryptographically confirm
   proof-of-possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "kid" (key ID) member identifying the
   key."

On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:
My brain hurt trying to parse = the first sentence/paragraph from section 3: 
   "The presenter of a JWT declares that it =
possesses a particular key
   and that the recipient can cryptographically confirm proof-of-
   possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object, with
   the JSON object containing a "jwk" (JSON Web Key) or "kid" (key ID)
   member identifying the key."
The issuer = includes the "cnf" claim and makes the declaration not the presenter. = Sure, the presenter may be the issuer but that's a special case.

Isn't it more accurate to say that it is = the issuer who declares that the presenter can confirm itself by some = cryptographic proof-of-possession of the key identified by the "cnf" = claim? Or something more like that...



 =


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


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

= --Apple-Mail=_13F152D1-9FFF-41B7-83C4-41F16B82817D-- --Apple-Mail=_04C3EC02-57E1-46DF-ADD6-F153029B97D8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAzMjUxNTQ4MDFaMCMGCSqGSIb3DQEJBDEWBBRbGkbYchnslgwAyPkSiNJJ Qj2RMzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBXTt0xOvcK2Gt36HYnOfkUxzuLH/WSOV8jgoc0wvrufxrO0x0rkslW CAKBHMvvp8BqhcLH1Dz+Tuvis7chZpsn/AoQ7+BBklbsUmC1yTnRIEI42XVdPkch69ZbQrCD1TtV 0YfFpNR9g1LUDPwQ+VGD/pKQ+w06SCMtgAUon8X2oTqIFhTs2djMEi8JzwrnKyLgCVTuncsUQHCs 6VEY+tVQev9mD00xvH1SACQtL8/ba7eBOXQWwi4e3cgWjxvoCMnCHc11gTqOuKYpGozFEgbagNnM nRHaCWToRQlXQS55cfUT3q0EUcfwKfw+UL9s8wfa58ay9+IcgyAdT4P8TikVAAAAAAAA --Apple-Mail=_04C3EC02-57E1-46DF-ADD6-F153029B97D8-- From nobody Wed Mar 25 11:56:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAB11B2A3A; Wed, 25 Mar 2015 11:56:26 -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] autolearn=ham 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 bX3OpDrjsh6j; Wed, 25 Mar 2015 11:56:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB701B2AB1; Wed, 25 Mar 2015 11:56:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150325185624.24157.82633.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 11:56:24 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-27.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 18:56:26 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-27.txt Pages : 40 Date : 2015-03-25 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-27 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 25 12:08:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B571B2B70 for ; Wed, 25 Mar 2015 12:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 WbR4d2Ewg_jU for ; Wed, 25 Mar 2015 12:08:14 -0700 (PDT) Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982E51A89C7 for ; Wed, 25 Mar 2015 12:08:09 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKVRMHmdWXrDTsNU5Xho+y/TGzTSYuT/1J@postini.com; Wed, 25 Mar 2015 12:08:09 PDT Received: by igcau2 with SMTP id au2so161312igc.1 for ; Wed, 25 Mar 2015 12:08:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=VXPxuOfFbyR8ZxxvVhkdVQ6I4XsNr5ZNMspDRxI6OTk=; b=TX2WOR+ZpkVjpHSRMeLtX2JN93PGEkV86Q65gdPDf5r0WCSNiMaMT2kCeU0IKR0Uj3 TQo9W511+jK3UXIU05YmbgH1bt2fKvvKpg37ovm++wSdPXXyiEmF7FKQ1Yp+JINt70s0 Ru6YvATJCi9nRMSCQ9LRItSHA61s9yLP2Grxd3A88NtG1oAnTOHGLSIy48XGBJkalmyP BS4+sIWz9wykxAlVKv7uksu5TyN+OLwEkog0AsgrjV9TUq7zFuczYUQDYlr4Exqszpnj qdeMMQIRP0s+p2AmiPMnHAlDSu6OWbDdG1YSPdBHDRl3tVzXcdcwoMd15Cawl7aWevuV 0/mg== X-Gm-Message-State: ALoCoQnEMHVqgvkrdf9cVQIXebLeX3BkR+BRlism0fFpsjQw8jkl14Ai5Ig5sM3f3IZbQQf83dBxTrKFUwJ1YWq5BYT2POIl7jfJgKsT7XulzDXgPBjsjmwoiFnhcwIJoNqbGObxJaJo X-Received: by 10.50.66.141 with SMTP id f13mr31194094igt.47.1427310488930; Wed, 25 Mar 2015 12:08:08 -0700 (PDT) X-Received: by 10.50.66.141 with SMTP id f13mr31194078igt.47.1427310488776; Wed, 25 Mar 2015 12:08:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Wed, 25 Mar 2015 12:07:38 -0700 (PDT) From: Brian Campbell Date: Wed, 25 Mar 2015 14:07:38 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=047d7bdc0dd2ab0b980512219e86 Archived-At: Subject: [OAUTH-WG] JWT Destination Claim X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:08:20 -0000 --047d7bdc0dd2ab0b980512219e86 Content-Type: text/plain; charset=UTF-8 Here are the slides that I rushed though at the end of the Dallas meeting: https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf And the -00 draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00 In an informal discussion earlier this week John B. suggested that some additional thinking and/or clarification is needed with regard to what parts of the URI to include and check. Particularly with respect to query and fragment. And he's probably right. --047d7bdc0dd2ab0b980512219e86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are the slides that I rushed though at the end o= f the Dallas meeting:

In a= n informal discussion earlier this week John B. suggested that some additio= nal thinking and/or clarification is needed with regard to what parts of th= e URI to include and check. Particularly with respect to query and fragment= . And he's probably right.
--047d7bdc0dd2ab0b980512219e86-- From nobody Wed Mar 25 12:16:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B456D1B2BC9 for ; Wed, 25 Mar 2015 12:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 XapVcWrKemVO for ; Wed, 25 Mar 2015 12:16:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779BE1B2BA0 for ; Wed, 25 Mar 2015 12:16:31 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.125.14; Wed, 25 Mar 2015 19:16:29 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Wed, 25 Mar 2015 19:16:29 +0000 From: Mike Jones To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] JWT Destination Claim Thread-Index: AQHQZy8UtPGlm/S3A0OWCF3lW8DO0p0tkXxw Date: Wed, 25 Mar 2015 19:16:29 +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:370:136:254b:a821:d660:543a] authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(52604005)(377454003)(16236675004)(19300405004)(46102003)(2656002)(86612001)(33656002)(2950100001)(76576001)(107886001)(74316001)(106116001)(19617315012)(19625215002)(2900100001)(77156002)(15975445007)(87936001)(99286002)(50986999)(92566002)(86362001)(77096005)(76176999)(19580395003)(19580405001)(54356999)(19609705001)(122556002)(40100003)(102836002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 052670E5A4 Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442687E4C3862894786536FF50B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 19:16:29.1638 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [OAUTH-WG] JWT Destination Claim X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:16:33 -0000 --_000_BY2PR03MB442687E4C3862894786536FF50B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBwb3N0aW5nIHRoaXMsIEJyaWFuLiAgVG8gZ2V0IGl0IGRvd24gb24gdGhlIGxp c3QsIEnigJlsbCByZXBlYXQgbXkgY29tbWVudCBtYWRlIGluIHBlcnNvbiB0aGF0IGp1c3QgYXMg 4oCcYXVk4oCdIHVzZWQgdG8gYmUgc2luZ2xlLXZhbHVlZCBhbmQgZW5kZWQgdXAgYmVpbmcgbXVs dGktdmFsdWVkLCBJIHN1c3BlY3Qgc29tZSBhcHBsaWNhdGlvbnMgd291bGQgcmVxdWlyZSB0aGUg c2FtZSB0aGluZyBvZiDigJxkc3TigJ0g4oCTIGF0IGxlYXN0IHdoZW4g4oCcYXVk4oCdIGFuZCDi gJxkc3TigJ0gYXJlIGRpZmZlcmVudC4gIEFuZCBldmVuIGlmIOKAnGRzdOKAnSBiZWNvbWVzIG11 bHRpLXZhbHVlZCwgaXTigJlzIE9LIGZvciBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9ucyB0byByZXF1 aXJlIHRoYXQgaXQgYmUgc2luZ2xlLXZhbHVlZCBpbiB0aGVpciB1c2FnZS4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyNSwgMjAxNSAyOjA4 IFBNDQpUbzogb2F1dGgNClN1YmplY3Q6IFtPQVVUSC1XR10gSldUIERlc3RpbmF0aW9uIENsYWlt DQoNCkhlcmUgYXJlIHRoZSBzbGlkZXMgdGhhdCBJIHJ1c2hlZCB0aG91Z2ggYXQgdGhlIGVuZCBv ZiB0aGUgRGFsbGFzIG1lZXRpbmc6DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Mi9zbGlkZXMvc2xpZGVzLTkyLW9hdXRoLTEucGRmDQoNCkFuZCB0aGUgLTAwIGRyYWZ0Og0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0NGp3dC0wMA0K SW4gYW4gaW5mb3JtYWwgZGlzY3Vzc2lvbiBlYXJsaWVyIHRoaXMgd2VlayBKb2huIEIuIHN1Z2dl c3RlZCB0aGF0IHNvbWUgYWRkaXRpb25hbCB0aGlua2luZyBhbmQvb3IgY2xhcmlmaWNhdGlvbiBp cyBuZWVkZWQgd2l0aCByZWdhcmQgdG8gd2hhdCBwYXJ0cyBvZiB0aGUgVVJJIHRvIGluY2x1ZGUg YW5kIGNoZWNrLiBQYXJ0aWN1bGFybHkgd2l0aCByZXNwZWN0IHRvIHF1ZXJ5IGFuZCBmcmFnbWVu dC4gQW5kIGhlJ3MgcHJvYmFibHkgcmlnaHQuDQo= --_000_BY2PR03MB442687E4C3862894786536FF50B0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciBwb3N0 aW5nIHRoaXMsIEJyaWFuLiZuYnNwOyBUbyBnZXQgaXQgZG93biBvbiB0aGUgbGlzdCwgSeKAmWxs IHJlcGVhdCBteSBjb21tZW50IG1hZGUgaW4gcGVyc29uIHRoYXQganVzdCBhcyDigJxhdWTigJ0g dXNlZCB0byBiZSBzaW5nbGUtdmFsdWVkIGFuZCBlbmRlZCB1cA0KIGJlaW5nIG11bHRpLXZhbHVl ZCwgSSBzdXNwZWN0IHNvbWUgYXBwbGljYXRpb25zIHdvdWxkIHJlcXVpcmUgdGhlIHNhbWUgdGhp bmcgb2Yg4oCcZHN04oCdIOKAkyBhdCBsZWFzdCB3aGVuIOKAnGF1ZOKAnSBhbmQg4oCcZHN04oCd IGFyZSBkaWZmZXJlbnQuJm5ic3A7IEFuZCBldmVuIGlmIOKAnGRzdOKAnSBiZWNvbWVzIG11bHRp LXZhbHVlZCwgaXTigJlzIE9LIGZvciBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9ucyB0byByZXF1aXJl IHRoYXQgaXQgYmUgc2luZ2xlLXZhbHVlZCBpbiB0aGVpciB1c2FnZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMjUs IDIwMTUgMjowOCBQTTxicj4NCjxiPlRvOjwvYj4gb2F1dGg8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W09BVVRILVdHXSBKV1QgRGVzdGluYXRpb24gQ2xhaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBhcmUgdGhlIHNsaWRlcyB0aGF0IEkgcnVzaGVkIHRo b3VnaCBhdCB0aGUgZW5kIG9mIHRoZSBEYWxsYXMgbWVldGluZzo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItb2F1dGgtMS5wZGYiPmh0dHBz Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItb2F1dGgtMS5w ZGY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+QW5kIHRoZSAtMDAgZHJhZnQ6PGJyPg0KPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0NGp3dC0wMCI+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0NGp3dC0wMDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IGFuIGluZm9ybWFsIGRpc2N1c3Npb24gZWFybGllciB0aGlzIHdlZWsgSm9obiBCLiBzdWdnZXN0 ZWQgdGhhdCBzb21lIGFkZGl0aW9uYWwgdGhpbmtpbmcgYW5kL29yIGNsYXJpZmljYXRpb24gaXMg bmVlZGVkIHdpdGggcmVnYXJkIHRvIHdoYXQgcGFydHMgb2YgdGhlIFVSSSB0byBpbmNsdWRlIGFu ZCBjaGVjay4gUGFydGljdWxhcmx5IHdpdGggcmVzcGVjdCB0byBxdWVyeSBhbmQgZnJhZ21lbnQu IEFuZCBoZSdzDQogcHJvYmFibHkgcmlnaHQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB442687E4C3862894786536FF50B0BY2PR03MB442namprd_-- From nobody Wed Mar 25 12:19:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D931A8A9B for ; Wed, 25 Mar 2015 12:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 vQNDpLK4CmY1 for ; Wed, 25 Mar 2015 12:19:45 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4EB1B2AE9 for ; Wed, 25 Mar 2015 12:19:45 -0700 (PDT) Received: from mail-ig0-f173.google.com ([209.85.213.173]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKVRMKUPcgfLH3KRyJeq2jUv5s6WvjIVbk@postini.com; Wed, 25 Mar 2015 12:19:45 PDT Received: by igbud6 with SMTP id ud6so110675428igb.1 for ; Wed, 25 Mar 2015 12:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=y0NwKy4fRpD/xGELCvYLBjJtq4r4JW1aHsL1R6rA61g=; b=gzJv7kOeH/Jy8um2lFakjVJx29DKpUegLR0TzXPkcPNfvASxbEO4NPaHURVmOHDP/k 3TISGjOasNJMjdlc/m8q1JhLr1gVWQYbiJ0XgQ/WoePEVpChMSozk7aktmeyp5GCBXlu zIVz4gprudyYItTBrwxydAaIhuFbxGx2O5AoN/kv18nU1o3Q4x7zX1C83h60altIKhXN Ic7VKNjKZOca9QPxWW6eJ/Pp8W0vBtgudnwpDzFtt6jb70uTetwd4lJIaLGsivexsVwk IMsphFBo1gntkYubfAwW2psNQ1AZWHkNz+m38AigK9fTc/6VcupmGKU7D0Zq7Dg4967O fVdA== X-Gm-Message-State: ALoCoQlme9kZijwVtDYIf+Hi7wJUrjbU9kl6sE+WBefckPcSTIVKXqpa44qdYK9YfzLpf7GsEpuVOEU0Ai4xXIyi0vQ73yBKbh9+0XYu4JJsq91bNrNqjmMBhwnT7NxColusIeAo0xiZ X-Received: by 10.107.169.146 with SMTP id f18mr16326064ioj.6.1427311184645; Wed, 25 Mar 2015 12:19:44 -0700 (PDT) X-Received: by 10.107.169.146 with SMTP id f18mr16325962ioj.6.1427311183573; Wed, 25 Mar 2015 12:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Wed, 25 Mar 2015 12:19:13 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 25 Mar 2015 14:19:13 -0500 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11426ae414cea4051221c848 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Destination Claim X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:19:47 -0000 --001a11426ae414cea4051221c848 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, I did have that as an open issue in the draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A Though the way I worded it probably shows my bias. On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones wrote: > Thanks for posting this, Brian. To get it down on the list, I=E2=80=99l= l repeat > my comment made in person that just as =E2=80=9Caud=E2=80=9D used to be s= ingle-valued and > ended up being multi-valued, I suspect some applications would require th= e > same thing of =E2=80=9Cdst=E2=80=9D =E2=80=93 at least when =E2=80=9Caud= =E2=80=9D and =E2=80=9Cdst=E2=80=9D are different. And > even if =E2=80=9Cdst=E2=80=9D becomes multi-valued, it=E2=80=99s OK for p= articular applications to > require that it be single-valued in their usage. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, March 25, 2015 2:08 PM > *To:* oauth > *Subject:* [OAUTH-WG] JWT Destination Claim > > > > Here are the slides that I rushed though at the end of the Dallas meeting= : > > https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf > > > > And the -00 draft: > http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00 > > In an informal discussion earlier this week John B. suggested that some > additional thinking and/or clarification is needed with regard to what > parts of the URI to include and check. Particularly with respect to query > and fragment. And he's probably right. > --001a11426ae414cea4051221c848 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW, I did have that as an open issue in the draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A=

Though the way I worded it probably shows my bias.

On Wed, Mar 25, 2015 a= t 2:16 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for posting this, = Brian.=C2=A0 To get it down on the list, I=E2=80=99ll repeat my comment mad= e in person that just as =E2=80=9Caud=E2=80=9D used to be single-valued and= ended up being multi-valued, I suspect some applications would require the same thi= ng of =E2=80=9Cdst=E2=80=9D =E2=80=93 at least when =E2=80=9Caud=E2=80=9D a= nd =E2=80=9Cdst=E2=80=9D are different.=C2=A0 And even if =E2=80=9Cdst=E2= =80=9D becomes multi-valued, it=E2=80=99s OK for particular applications to= require that it be single-valued in their usage.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 25, 2015 2:08 PM
To: oauth
Subject: [OAUTH-WG] JWT Destination Claim

=C2=A0


--001a11426ae414cea4051221c848-- From nobody Wed Mar 25 13:24:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D321B2B71 for ; Wed, 25 Mar 2015 13:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Pr8xkDby9YJA for ; Wed, 25 Mar 2015 13:24:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7939D1A8738 for ; Wed, 25 Mar 2015 13:24:42 -0700 (PDT) Received: from [192.168.10.146] ([31.133.152.120]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Mbxdm-1Yt5lG17g6-00JKBe for ; Wed, 25 Mar 2015 21:24:40 +0100 Message-ID: <55131984.2090305@gmx.net> Date: Wed, 25 Mar 2015 21:24:36 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h6xxLQHDQ2M9NkeCaXELMgLdqxHwrWP8X" X-Provags-ID: V03:K0:IZAVUeJF7AAY4xcGtXRD9HftDKJeMwL6fe4cvldvIQGaWsw/tIx E/bIMz//nTpU9D+sL5t5TNBglROMmvMalsj3/g+EpDuGJu5WONFsfAdOKxHkTBvxZNKe5aw BBnhUrl3JCcw3s8VEQpSWepVyWHiyx4J9P5nu5oKIBzytR5d40/e2qBvUHAUpzOFuc38D29 BI2v2t7DXG69smvk93ctg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Meeting Room for Token Exchange Discussion Tonight X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:24:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h6xxLQHDQ2M9NkeCaXELMgLdqxHwrWP8X Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I reserved a meeting room for us. We will be in **Royal**. --h6xxLQHDQ2M9NkeCaXELMgLdqxHwrWP8X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVExmFAAoJEGhJURNOOiAtgj4H+wfXQ0bME6A+nZYWfvI8eSP+ UMWHlyCTM4GT6rKQSQA//77CnbeUNJ75M01OX+YgUFjaZTe80CllJlVirZ5sw4Fo o+jmyNGpCKrlP2twgcZAZcRYizfh/g3OdTasuZabIHQaszzxsc1f1zbb7T/PyDhR gAVsfZEGr/2/5lw3VXmqnZyjuY8TQbI8Euwd9BzJwiildH0k0HefFLKzT1YNhyfI /qQK64a7zs/O11Z6Ur9O7qkFQH+FuzkVeuYTMdpl++I6bc5WO+GdsvptuG8zJgSk USWwKfAhlIT7kz49CzTkXqQnBd6d3VrrxUZUxEJdrVR09IuUNQLXcwj+Yc1pM7Y= =x8DO -----END PGP SIGNATURE----- --h6xxLQHDQ2M9NkeCaXELMgLdqxHwrWP8X-- From nobody Wed Mar 25 13:34:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2351B2B7A for ; Wed, 25 Mar 2015 13:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 BklD5T_RQtMy for ; Wed, 25 Mar 2015 13:34:38 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 E9F591B2B78 for ; Wed, 25 Mar 2015 13:34:37 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2PKYYfY000848 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Mar 2015 20:34:35 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2PKYY4X017828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2015 20:34:34 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2PKYXn8012002; Wed, 25 Mar 2015 20:34:34 GMT Received: from dhcp-b2f0.meeting.ietf.org (/31.133.178.240) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Mar 2015 13:34:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: <55131984.2090305@gmx.net> Date: Wed, 25 Mar 2015 15:34:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55131984.2090305@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2070.6) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Meeting Room for Token Exchange Discussion Tonight X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:34:39 -0000 Unfortunately there is another BOF at 7:30. So I will have to pass. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 25, 2015, at 3:24 PM, Hannes Tschofenig = wrote: >=20 > I reserved a meeting room for us. We will be in **Royal**. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Mar 25 14:30:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28E51B2AB3 for ; Wed, 25 Mar 2015 14:30: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, SPF_PASS=-0.001] autolearn=ham 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 KoyPXzq9PShZ for ; Wed, 25 Mar 2015 14:30:31 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 0320C1A87BE for ; Wed, 25 Mar 2015 14:30:31 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so30582453obc.2 for ; Wed, 25 Mar 2015 14:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=REOdR4LhQnghbXG1edxNoFCkWXdzBiSVHgLu+/7r+5c=; b=Ykxjo6kYd4Mlf7Y78MFiK5i9Rm6g5w1UF/FTlK2V9TTlC8IkjX0sgivS2KcgLXLxRw BEcLZdxBVbJCenpd/xOx+hm9HNOzkRZoUvy1cPsuehAR4mzfgbP4CrFTZfNZyE4sU45Q lp3ET4pwjjRNnGzx6iAKpfC5AK1Pnm1wVVxTQv2aEBw4sLHwbnypZNPKMFT0sHJMXtJa dREfuwABIASQ/njVNepy1mgei9mG1Nrkp2oft7FPWluhwvCwHU2/g84yidFlj1g5ad3W 5w9chYTZ96N0X99QUDZ5h5M0aAyS9RUCJZW8edXJ2skaew+Mz+h68iHBny3TTqqHoVsA ZQsw== MIME-Version: 1.0 X-Received: by 10.202.63.132 with SMTP id m126mr8586282oia.33.1427319030415; Wed, 25 Mar 2015 14:30:30 -0700 (PDT) Received: by 10.60.141.230 with HTTP; Wed, 25 Mar 2015 14:30:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2015 06:30:30 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=001a113d660aca09330512239bd5 Archived-At: Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:30:34 -0000 --001a113d660aca09330512239bd5 Content-Type: text/plain; charset=UTF-8 I have refreshed the draft which talks about what is being discussed in Section 3 paragraph 2 as: http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-03 It just talks about Sender Constraint now, dropping all the things about Key Confirmation. Cheers, Nat 2015-03-25 22:37 GMT+09:00 Nat Sakimura : > Dear OAuthers: > > Here is my belated review comments on > draft-ietf-oauth-proof-of-possession-02 > > Below, [POPA] stands for > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 > > Abstract > ============ > It is probably better to spell out that this document is describing the > JWT format that can be used for sender constraint (5.2 of [POPA]) and key > confirmation (5.3 of [POPA]). This will make it easier for the reader to > understand what this document aims at. > > Accordingly, we should consider the title change to something like: > JWT Sender Confirmation Token Syntax > OR > borrowing from the financial concept which I believe is the origin of the > concept of "bearer token", > JWT Registered Token Syntax > -- here, "Registered" mean that either the sender constraint or key > confirmation is registered within or in conjunction with the token. > > 1. Introduction > ============== > Consider referencing draft-ietf-oauth-pop-architecture. > It will be clearer for the reader then, and the text will be shorter. > > 2. Terminology - Presenter > ======================== > Sentence 1 > ------------------- > Not sure if the first sentence is accurately reflecting the intent. > It excludes rogue party presenting the token (and fails) from presenter. > If so, it is fine but using more qualified term like "authorized > presenter" may make it easier > for the reader to parse. > > Otherwise revise the definition. > > Sentence 2 > ------------------- > "issuer or a party different from the issuer" is not constraining anything > and meaningless. > There are more easier to parse and accurate text coming in the main text, > too. > Drop. > > 3. Proof-Of-Posession Representation > ============================== > Title > --------- > Perhaps "Sender Representation in JWT" is more reflective of the content. > > Para 2 > ------------- > The paragraph describes two ways of sender confirmation: > (1) Sender Constraint > (2) Key Confirmation > It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the > terminology. > > Then, it goes on to describe (1) very briefly, in which it is just > spelling out "iss" and "sub". > > I understand the use of sub in this section comes down from SAML but I > feel that some separation between sub and presenter would be nice. > > For example, when I am presenting the token using an app that I installed > on my iPhone, the presenter is that app and not me, while the sub still may > be me. The app is the authorized presenter/party (azp) of the token. The > JWT may well be about the sub but presented by some software component that > should be independently identified. > > So my proposal is to create a new subsection on (1) for the completeness, > which is going to be a new 3.1, and to use a claim like "azp" instead of > "sub" to identify the presenter. Less overload would cause less confusion > later, IMHO. > > 3.1 > ====== > Title > -------- > Perhaps "Confirmation Key Representation for an Asymmetric Key" is more > reflective of the content. > > 3.2 > ======== > Title > ----------- > Perhaps "Confirmation Key Representation for a Symmetric Key" is more > reflective of the content. > > Last Para > ----------------- > I feel a bit like needing to sniff into the content of jwk to find out > what type may not be optimal, though I do not have a concrete proposal a > this time. > > 3.3 > ====== > Title > --------- > Perhaps "Confirmation Key Representation by Key ID" is more reflective of > the content. > > Para 1 > ----------- > There has been some discussion of using thumbprint instead of a blob > "kid". > This is a valid option. If we are to overload the "kid" member for this > purpose, we need to find a way to signal that it is a thumbprint. > It may very well be better to define a separate member name then for the > thumbprint. The title then changes to "-- by Key ID" to "-- by reference". > > Also, it is conceivable to use the combination of "kid" and "jku". This > aspect is not spelled out here but appears that some magic happens for the > key distribution. > > 3.4 > ======== > Since "cnf" appears before 3.4, it may be better to bring 3.4 at the > front. > > 5.2.2 > ========= > Add "azp" and "jkt". > > o Confirmation Method Value: "azp" > o Confirmation Method Description: Client ID of the Authorized Presenter > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > > o Confirmation Method Value: "jkt" > o Confirmation Method Description: JWK Thumbprint of the Confirmation Key > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > > o Confirmation Method Value: "jku" > o Confirmation Method Description: JWK URI of the Confirmation Key > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > Privacy Consideration > ======================== > It is missing privacy consideration. It is not required per se, but since > Key Confirmation method with ephemeral key can be less privacy intrusive > compared to other sender confirmation method so adding some text around it > may be a good idea. > > Best, > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a113d660aca09330512239bd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have refreshed the draft which talks about what is being= discussed in Section 3 paragraph 2 as:=C2=A0

http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-03

It just talks about Sender Constraint now, dropping= all the things about Key Confirmation.=C2=A0

Chee= rs,=C2=A0

Nat

2015-03-25 22:37 GMT+09:00 Nat Sakimura <sakimura@gmail.com>:
Dear OAuthers:=C2=A0

Here is my belate= d review comments on=C2=A0draft-i= etf-oauth-proof-of-possession-02

Below, [POPA] stands for https://tools.ietf.org/html/= draft-ietf-oauth-pop-architecture-01

Abstract<= /div>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
It is probably bet= ter to spell out that this document is describing the JWT format that can b= e used for sender constraint (5.2 of [POPA]) and key confirmation (5.3 of [= POPA]). This will make it easier for the reader to understand what this doc= ument aims at.=C2=A0

Accordingly, we should consid= er the title change to something like:=C2=A0
JWT Sender = Confirmation Token Syntax=C2=A0
=C2=A0 OR
borrowing fro= m the financial concept which I believe is the origin of the concept of &qu= ot;bearer token",=C2=A0
JWT Registered Token Syntax
-- here, "Registered" mean that either the sender constraint or= key confirmation is registered within or in conjunction with the token.=C2= =A0

1. Introduction
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Consider referencing draft-ietf-oauth-po= p-architecture.=C2=A0
It will be clearer for the reader then, and= the text will be shorter.=C2=A0

2. Terminology - = Presenter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Sentence 1
-------------------
=
Not sure if the first sentence is accurately reflecting the intent.=C2= =A0
It excludes rogue party presenting the token (and fails) from= presenter.=C2=A0
If so, it is fine but using more qualified term= like "authorized presenter" may make it easier=C2=A0
f= or the reader to parse.=C2=A0

Otherwise revise the= definition.=C2=A0

Sentence 2
----------= ---------
"issuer or a party different from the issuer"= is not constraining anything and meaningless.=C2=A0
There are mo= re easier to parse and accurate text coming in the main text, too.=C2=A0
Drop.=C2=A0

3. Proof-Of-Posession Represen= tation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Title
---------
=
Perhaps "Sender Representation in JWT" is more reflective of= the content.=C2=A0

Para 2
---------= ----
The paragraph describes two ways of sender confirmation:=C2= =A0
(1) Sender Constraint
(2) Key Confirmation
It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the ter= minology.=C2=A0

Then, it goes on to describe (1) v= ery briefly, in which it is just spelling out "iss" and "sub= ".=C2=A0

I understand the use of sub in this secti= on comes down from SAML but I feel that some separation between sub and pre= senter would be nice.

For example, when I am presenting the token u= sing an app that I installed on my iPhone, the presenter is that app and no= t me, while the sub still may be me. The app is the authorized presenter/pa= rty (azp) of the token.=C2=A0The JWT may well be about the sub but presente= d by some software component that should be independently identified. =C2= =A0

So my proposal is to create a new subsection on (1) for the com= pleteness, which is going to be a new 3.1, and to use a claim like "az= p" instead of "sub" to identify the presenter. Less overload= would cause less confusion later, IMHO.

3.1
=
=3D=3D=3D=3D=3D=3D
Title
--------
Perhap= s "Confirmation Key Representation for an Asymmetric Key" is more= reflective of the content.=C2=A0

3.2
= =3D=3D=3D=3D=3D=3D=3D=3D
Title
-----------
Pe= rhaps "Confirmation Key Representation for a Symmetric Key" is mo= re reflective of the content.=C2=A0

Last Para<= /div>
-----------------
I feel a bit like needing to sniff in= to the content of jwk to find out what type may not be optimal, though I do= not have a concrete proposal a this time.=C2=A0

3= .3
=3D=3D=3D=3D=3D=3D
Title
---------
Perhaps "Confirmation Key Representation by Key ID" is more re= flective of the content.=C2=A0

Para 1
-----------
There has been some discussion of using thumbprint = instead of a blob "kid".=C2=A0
This is a valid option. = If we are to overload the "kid" member for this purpose, we need = to find a way to signal that it is a thumbprint.=C2=A0
It may ver= y well be better to define a separate member name then for the thumbprint. = The title then changes to "-- by Key ID" to "-- by reference= ".=C2=A0

Also, it is conceivable to use the c= ombination of "kid" and "jku". This aspect is not spell= ed out here but appears that some magic happens for the key distribution.= =C2=A0

3.4=C2=A0
=3D=3D=3D=3D=3D=3D= =3D=3D
Since "cnf" appears before 3.4, it may be better= to bring 3.4 at the front.=C2=A0

5.2.2
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Add "azp" and "j= kt".=C2=A0

o =C2=A0Confirmation Method Value: &quo= t;azp"
o =C2=A0Confirmation Method Description: Client ID of the Au= thorized Presenter
o =C2=A0Change Controller: IESG
o =C2=A0Specificat= ion Document(s): Section [TBD] of [[ this document ]]


o =C2=A0Co= nfirmation Method Value: "jkt"
o =C2=A0Confirmation Method Des= cription: JWK Thumbprint of the Confirmation Key
o =C2=A0Change Controll= er: IESG
o =C2=A0Specification Document(s): Section [TBD] of [[ this doc= ument ]]


o =C2=A0Confirmation Method Value: "jku"
o= =C2=A0Confirmation Method Description: JWK URI of the Confirmation Key
= o =C2=A0Change Controller: IESG
o =C2=A0Specification Document(s): Secti= on [TBD] of [[ this document ]]

Privacy Consideration
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
It is missing privacy consideration. It is not required pe= r se, but since Key Confirmation method with ephemeral key can be less priv= acy intrusive compared to other sender confirmation method so adding some t= ext around it may be a good idea.=C2=A0

Best,= =C2=A0
--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--001a113d660aca09330512239bd5-- From nobody Wed Mar 25 16:57:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7691A88AD for ; Wed, 25 Mar 2015 16:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Pkk-YDwyJFn9 for ; Wed, 25 Mar 2015 16:57:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26B71A1A52 for ; Wed, 25 Mar 2015 16:57:34 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BL2PR03MB436.namprd03.prod.outlook.com (10.141.92.26) with Microsoft SMTP Server (TLS) id 15.1.125.14; Wed, 25 Mar 2015 23:57:13 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0118.021; Wed, 25 Mar 2015 23:57:13 +0000 From: Anthony Nadalin To: Brian Campbell , Mike Jones Thread-Topic: [OAUTH-WG] JWT Destination Claim Thread-Index: AQHQZy8UdSaBmebrPEiJO4o1OYgnRZ0tkgWAgAAAxICAAE2sQA== Date: Wed, 25 Mar 2015 23:57:13 +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: [166.173.187.151] authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB436; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(52604005)(24454002)(86362001)(86612001)(87936001)(76176999)(50986999)(74316001)(99286002)(2656002)(106116001)(77156002)(62966003)(54356999)(76576001)(1511001)(66066001)(2561002)(33656002)(19580405001)(19580395003)(16297215004)(122556002)(40100003)(46102003)(2900100001)(2950100001)(102836002)(15975445007)(16236675004)(92566002)(19617315012)(2421001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB436; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BL2PR03MB436; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB436; x-forefront-prvs: 052670E5A4 Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123419B3AE4F837B3E249451A60B0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 23:57:13.1258 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB436 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Destination Claim X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:57:37 -0000 --_000_BN3PR0301MB123419B3AE4F837B3E249451A60B0BN3PR0301MB1234_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable There some folks out there that are using AUD to mean DST. Adding DST is co= nfusing, if you want to use it that's fine but don't see a need to standard= ize every claim that someone comes up with Sent from my Windows Phone ________________________________ From: Brian Campbell Sent: =FD3/=FD25/=FD2015 2:19 PM To: Mike Jones Cc: oauth Subject: Re: [OAUTH-WG] JWT Destination Claim FWIW, I did have that as an open issue in the draft: http://tools.ietf.org/= html/draft-campbell-oauth-dst4jwt-00#appendix-A Though the way I worded it probably shows my bias. On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones > wrote: Thanks for posting this, Brian. To get it down on the list, I=92ll repeat = my comment made in person that just as =93aud=94 used to be single-valued a= nd ended up being multi-valued, I suspect some applications would require t= he same thing of =93dst=94 =96 at least when =93aud=94 and =93dst=94 are di= fferent. And even if =93dst=94 becomes multi-valued, it=92s OK for particu= lar applications to require that it be single-valued in their usage. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Brian Campbell Sent: Wednesday, March 25, 2015 2:08 PM To: oauth Subject: [OAUTH-WG] JWT Destination Claim Here are the slides that I rushed though at the end of the Dallas meeting: https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf And the -00 draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00 In an informal discussion earlier this week John B. suggested that some add= itional thinking and/or clarification is needed with regard to what parts o= f the URI to include and check. Particularly with respect to query and frag= ment. And he's probably right. --_000_BN3PR0301MB123419B3AE4F837B3E249451A60B0BN3PR0301MB1234_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
There some fo= lks out there that are using AUD to mean DST. Adding DST is confusing, if y= ou want to use it that's fine but don't see a need to standardize every cla= im that someone comes up with

Sent from my Windows Phone
From: Brian Campbell
Sent: =FD3/= =FD25/=FD2015 2:19 PM
To: Mike Jones
Cc: oauth
Subject: Re: [= OAUTH-WG] JWT Destination Claim

FWIW, I did have that as an open issue in the draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A <= br>
Though the way I worded it probably shows my bias.

On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Thanks for posting this= , Brian.  To get it down on the list, I=92ll repeat my comment made in= person that just as =93aud=94 used to be single-valued and ended up being multi-valued, I suspect some applications would require the same thi= ng of =93dst=94 =96 at least when =93aud=94 and =93dst=94 are different.&nb= sp; And even if =93dst=94 becomes multi-valued, it=92s OK for particular ap= plications to require that it be single-valued in their usage.

 

    = ;            &n= bsp;            = ;            &n= bsp;            = ;      -- Mike

 

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 25, 2015 2:08 PM
To: oauth
Subject: [OAUTH-WG] JWT Destination Claim


--_000_BN3PR0301MB123419B3AE4F837B3E249451A60B0BN3PR0301MB1234_-- From nobody Wed Mar 25 17:34:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71B1A0461 for ; Wed, 25 Mar 2015 17:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 G7WVVbM1e7qq for ; Wed, 25 Mar 2015 17:34:07 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145041A0179 for ; Wed, 25 Mar 2015 17:34:06 -0700 (PDT) Received: from mail-ig0-f179.google.com ([209.85.213.179]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKVRNT/a130hgvd/wCUgZdKijACPmRL2tL@postini.com; Wed, 25 Mar 2015 17:34:07 PDT Received: by igcau2 with SMTP id au2so4381594igc.1 for ; Wed, 25 Mar 2015 17:34:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4pJ1OXghEhwdCwM2I8/2qPBNCS4kGMt0PG7JG2h5xkg=; b=BejTqlkLeCzHOTI/4gcb/MxHHHCDzWhB+ntrRcv46uEi/6knb9pIvRh5G2vPMkhn18 4YhzlzEz/QxvH1uMbz7UQIgnSG4mHA+8PJGICpX9lmRKZHDP7Vt5TKKwelCeFm2CcgUA xva73sMMc3VZBn9RetVoiHycqqFPY7pp6LQFjYiR6GaQG4H+ZNPz+vbK4EGDydFcDL+z q9D2dXqMbOCqCfPSvnTfCBm0ZGnLyRMeh60FWXR5BYqJpA9PicTMh589pteKJ3IZO+Rc ZWLolj5lcuxrLHeFDgI/6nuU2UPW74d6I9qrArGDbbKvkPpafuqMwtUBuLvURbSN//vB /3qQ== X-Received: by 10.42.94.65 with SMTP id a1mr34062385icn.1.1427330041543; Wed, 25 Mar 2015 17:34:01 -0700 (PDT) X-Gm-Message-State: ALoCoQkmswzCxD05EUQeknblRgUJfFtpJy15jolKSqw/g1oILwSnQb6Q5Jk9phgK2z4NigWnw8aI7772CXT9h4qN7P0394izXt9cT3qn7S6ylZWD6JH6i0NN8Db72WMoqHF5+d41QmaZ X-Received: by 10.42.94.65 with SMTP id a1mr34062359icn.1.1427330041192; Wed, 25 Mar 2015 17:34:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Wed, 25 Mar 2015 17:33:31 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 25 Mar 2015 19:33:31 -0500 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=20cf303345f315b7100512262c7c Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Destination Claim X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 00:34:09 -0000 --20cf303345f315b7100512262c7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tony, thanks as always for your thoughtful, well reasoned, and helpful comments. I'm well aware of the potential for confusion, which is why I endeavored to address the differences between aud and dst with text in the draft. I do appreciate your permission to use it ourselves and I'll be sure to let the engineers that have already deployed it know that they have your blessing. As I said on Monday, it struck me as something that would have value well beyond our own usage and that was why I wanted to start a conversation about standardization. You're stance on that has been made pretty clear, thanks. On Wed, Mar 25, 2015 at 6:57 PM, Anthony Nadalin wrote: > There some folks out there that are using AUD to mean DST. Adding DST is > confusing, if you want to use it that's fine but don't see a need to > standardize every claim that someone comes up with > > Sent from my Windows Phone > ------------------------------ > From: Brian Campbell > Sent: =E2=80=8E3/=E2=80=8E25/=E2=80=8E2015 2:19 PM > To: Mike Jones > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Destination Claim > > FWIW, I did have that as an open issue in the draft: > http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A > > Though the way I worded it probably shows my bias. > > On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones > wrote: > >> Thanks for posting this, Brian. To get it down on the list, I=E2=80=99= ll >> repeat my comment made in person that just as =E2=80=9Caud=E2=80=9D used= to be >> single-valued and ended up being multi-valued, I suspect some applicatio= ns >> would require the same thing of =E2=80=9Cdst=E2=80=9D =E2=80=93 at least= when =E2=80=9Caud=E2=80=9D and =E2=80=9Cdst=E2=80=9D are >> different. And even if =E2=80=9Cdst=E2=80=9D becomes multi-valued, it= =E2=80=99s OK for particular >> applications to require that it be single-valued in their usage. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian >> Campbell >> *Sent:* Wednesday, March 25, 2015 2:08 PM >> *To:* oauth >> *Subject:* [OAUTH-WG] JWT Destination Claim >> >> >> >> Here are the slides that I rushed though at the end of the Dallas meetin= g: >> >> https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf >> >> >> >> And the -00 draft: >> http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00 >> >> In an informal discussion earlier this week John B. suggested that some >> additional thinking and/or clarification is needed with regard to what >> parts of the URI to include and check. Particularly with respect to quer= y >> and fragment. And he's probably right. >> > > --20cf303345f315b7100512262c7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tony, thanks as always for your thoughtful, well reas= oned, and helpful comments.

I'm well aware of the potential for= confusion, which is why I endeavored to address the differences between au= d and dst with text in the draft.

I do appreciate your permission t= o use it ourselves and I'll be sure to let the engineers that have alre= ady deployed it know that they have your blessing.

As I = said on Monday, it struck me as something that would have value well beyond= our own usage and that was why I wanted to start a conversation about stan= dardization. You're stance on that has been made pretty clear, thanks. =



On Wed, Mar 25, 2015 at 6:57 PM, Anthony Nadalin <to= nynad@microsoft.com> wrote:
There some fol= ks out there that are using AUD to mean DST. Adding DST is confusing, if yo= u want to use it that's fine but don't see a need to standardize ev= ery claim that someone comes up with

Sent from my Windows Phone
From: Brian Campbell
Sent: =E2=80= =8E3/=E2=80=8E25/=E2=80=8E2015 2:19 PM
To: Mike Jones
Cc: oauth
Subject: Re: [O= AUTH-WG] JWT Destination Claim

FWIW, I did have that as an open issue in the draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A <= br>
Though the way I worded it probably shows my bias.

On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Thanks for posting this, = Brian.=C2=A0 To get it down on the list, I=E2=80=99ll repeat my comment mad= e in person that just as =E2=80=9Caud=E2=80=9D used to be single-valued and= ended up being multi-valued, I suspect some applications would require the same thi= ng of =E2=80=9Cdst=E2=80=9D =E2=80=93 at least when =E2=80=9Caud=E2=80=9D a= nd =E2=80=9Cdst=E2=80=9D are different.=C2=A0 And even if =E2=80=9Cdst=E2= =80=9D becomes multi-valued, it=E2=80=99s OK for particular applications to= require that it be single-valued in their usage.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 25, 2015 2:08 PM
To: oauth
Subject: [OAUTH-WG] JWT Destination Claim



--20cf303345f315b7100512262c7c-- From nobody Thu Mar 26 11:31:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651551A90BE for ; Thu, 26 Mar 2015 11:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 14E8vSWs-v9P for ; Thu, 26 Mar 2015 11:31:28 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C526A1A9241 for ; Thu, 26 Mar 2015 11:31:24 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-5e-5514507ad7c0 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 5F.A4.03493.A7054155; Thu, 26 Mar 2015 14:31:22 -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 t2QIVLoE024957 for ; Thu, 26 Mar 2015 14:31:22 -0400 Received: from dhcp-b47c.meeting.ietf.org (dhcp-b47c.meeting.ietf.org [31.133.180.124]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2QIVJ6l028297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Mar 2015 14:31:21 -0400 From: Justin Richer X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_EB1D3C9A-55CC-4C8C-981D-8668655EA882"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Thu, 26 Mar 2015 13:31:17 -0500 Message-Id: To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixCmqrVsVIBJqsGS/hcXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseXTUeaCT8oVy990sjUwzpTtYuTkkBAwkbh3aB0rhC0mceHe erYuRi4OIYHFTBJren8yQjjHGCW2N/5khXBeMklceL+WDaSFTUBVYv7KW0wQ7VISTa+PgXUw C0xhlDj69D87SEJYQEHi08dtYEUsQA1vmi6wgNi8AlYSLz5dAqsREVCXWHP+JxNE3EBi7qkv QDYH0FB5iZ5N6RMY+WYhGzsLSRmIzSygLbFs4WtmCFtTYn/3chYIW15i+9s5UHFLicUzb0DF bSVu9S2A6rWTeDRtEesCRo5VjLIpuVW6uYmZOcWpybrFyYl5ealFuuZ6uZkleqkppZsYQQHO 7qKyg7H5kNIhRgEORiUe3h/9wqFCrIllxZW5hxglOZiURHk3uomECvEl5adUZiQWZ8QXleak Fh9iVAHa9WjD6guMUix5+XmpSiK8bh5AdbwpiZVVqUX5MGXSHCxK4rybfvCFCAmkJ5akZqem FqQWwWRlODiUJHjt/IEaBYtS01Mr0jJzShDSTBychxglOHiAhvuB1PAWFyTmFmemQ+RPMSpK ifN+9QNKCIAkMkrz4HphiekVozjQW8K8j0GqeIBJDa77FdBgJqDB5/L5QAaXJCKkpBoYDQra Qwu+Xp4vdH1xoMD/4gT/DmH1uaK+TQsvTt9c2Hnq3bru6pxt19t7OKeeMnp+4nH8rbN3F5n4 Sf2Z+aN4ltsGzekPS4KrtY5UzMhhlZgYz7BCb6KQk2W/jaAM28xvE4VsuaVf+X4KErsnXblw 9YEvb//EPu67KW9sKH2LZYFzWXL05Ug9JZbijERDLeai4kQAvsUqfScDAAA= Archived-At: Subject: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:31:30 -0000 --Apple-Mail=_EB1D3C9A-55CC-4C8C-981D-8668655EA882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap = draft. [ Client ] -> [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of =E2=80=9C= I got a token, I get another token based on this to call someone = else=E2=80=9D. It=E2=80=99s also analogous to the refresh token flow, = but with access tokens going in and out. I=E2=80=99ve deployed this = setup several times in different service deployments. Even though there = is a performance hit in the additional round trips (as Phil brought up = in another thread), in these cases the desire to have the tokens hold = least privilege access rights (smallest set of scopes per service) = outweighed any performance hit (which was shown to be rather small in = practice). What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for = what it is: a way for a token issuer to communicate to a token service = specific actions. At a high level, the spec would be something like: 1. How to swap a token at an AS 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as = semantics 2. What to do (as an AS/RS) with a JWT with act-as semantics 3. How to create a JWT with on-behalf-of semeantics 4. What to do with a JWT with on-behalf-of-semantics 5. How to possibly represent these semantics with something other than = a JWT Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This = works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens. =E2=80=94 Justin --Apple-Mail=_EB1D3C9A-55CC-4C8C-981D-8668655EA882 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVFFB1AAoJEDPAngkbd+w9vasIAIkWZynrGqASovNcXB+Epe22 CxHzHX4kn9kMalHjD/1IIn9hP7sa0yVOC9J2CeLqkBOA8iBdojPQ55S7JZkj+mBe euqBv0eNX1GA8YSuRw0Q1HI3vgST9rSjCqFUvywi1t8G1zc4GxC6nh+TUquuj88d xygh7ffvI6GOZ45rxBqDDaKETH4iTSkyp094Y2FSIU2qG5cQp+3CoXFQGJHB61ep p78BLBaK4izd2iatKlBd1klMQ2FMMs+FBgD59nzx0szm/Ac8YmyBQYZvzLlVsO7u bRjYr73QD+WgLtYgJSWTURrs0il3hHhPUh+PsSDhIOFwxC0zef8HMro6HvJGWTk= =nfF9 -----END PGP SIGNATURE----- --Apple-Mail=_EB1D3C9A-55CC-4C8C-981D-8668655EA882-- From nobody Thu Mar 26 12:24:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A7C1B2D99 for ; Thu, 26 Mar 2015 12:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 7039oLKM_pCZ for ; Thu, 26 Mar 2015 12:24:10 -0700 (PDT) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EFD1A8785 for ; Thu, 26 Mar 2015 12:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427397848; bh=r8wgzlbCvGlBu1meduhzpsiBwJbost2HAXiOSSyquZE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=BWtbR6ithPBheksNPb4AQP3GvRosY/jfTbAW56XnqDbgpt3VRn6yU6z4O+qEH7VI9+GsIsoIhvj92s0iB7omfADTf+67DYCTkdyOMQ9IfA8R4NX4T1EWK8jVbOJUwxiGjWBBzctaCrV2i+KqqlEj4rESBd67CBhHbrswIQlt7bMo2UX8ZB6Rf2qgu/vI+RUs5HNtaJO/nEX/5T6dKSIAYn0ogZIc9NQt3DUZZNBuRaeTYYqfiON6ymsbpNBZA1FiFN+yBwnwPAeqit7X2oNSQDOKQtDD9sYku89V8G7C3+HLKOTpHSYLXwS4/1uc6dBVMwPBcvqrhPOwfUpsbzRfrA== Received: from [98.139.170.180] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 19:24:08 -0000 Received: from [98.139.212.209] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 19:24:08 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 19:24:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 245472.32364.bm@omp1018.mail.bf1.yahoo.com X-YMail-OSG: 0gnuDYUVM1kd1ZrpkCj9q2U7GSG2z.DcTho4WR0niYQC_5ds2yIz.wCMeGyQFzd oCo3uwNiBiMUhPerbgD7HXVSralqh2fZVo3f37rUStDQgxbx20L8jxfeGA1AiXnjBhKQ4Zzkhe6q z44Zd0pSj2IYo.9Su_s_1m6rlPrAUht49oOhZDQ0KmUuuGaBoXU8NALGMA_yPDcdBCQj044ar5oQ 0ZPgvZsAxrpG_cmPsqD0GITe6.T3fFdZ9p9Pu9i1QgokYX2WzUh.9TVEEunuXJwUC3wMQjCN1vjB SgvYtMEkn1yuD8rg.gnqAdYxZa9D8Nkm1O2jTqLbmFKnnseb5_Wev0I8VkoyD3yER174pLP3q1Y9 xiZRRar0EKQi.GgpWKo2PNBGLA92W0MB3kb4apUURh0SuWpZg_FnYyUt87Vc1M.6pX2KqraucRAi 9jP072usPC6shie_Ta.Ux5gmOcJ9Rjv08VE6DSUACT9JcMfuEDrWyZCOwulDz3Z7yPuxtjykoF85 WKAvvWwCc3yUF166EJyDinN8PsBoAirOYe4_aNSE4 Received: by 76.13.26.108; Thu, 26 Mar 2015 19:24:07 +0000 Date: Thu, 26 Mar 2015 19:24:07 +0000 (UTC) From: Bill Mills To: Justin Richer , "" Message-ID: <266610870.2904039.1427397847438.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2904038_671565861.1427397847434" Archived-At: Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:24:12 -0000 ------=_Part_2904038_671565861.1427397847434 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So why can't the access tokne simply be re-used as a refresh token? =C2=A0W= hy would it need a new grant type at all? =20 On Thursday, March 26, 2015 11:31 AM, Justin Richer = wrote: =20 As requested after last night=E2=80=99s informal meeting, here is the toke= n chaining use case that I want to see represented in the token swap draft. [ Client ]=C2=A0 ->=C2=A0 [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, with s= copes [A, B, C] in order to call service A, which requires all three scopes= . Service A (an RS) accepts this token since it has its scope, and then nee= ds to call service B in turn, which requires scopes [B, C]. It could just r= e-send the token it got in, AT1, but that would give the downstream RS the = ability to call services with scope [ A ] and it should not be allowed to d= o that. To limit exposure, service A calls a token swap at the AS to create= AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting= a downscoped token based on AT1. Service A then acts as an OAuth client to= call service B, now acting as an RS to service A=E2=80=99s client, and can= fulfill the request. And it=E2=80=99s turtles all the way down: Service B = can also call service C, and now B acts as a client, requesting AT3 with sc= ope [ C ] based on AT2, and sending AT3 to service C. This prevents C from = being able to call B or A, both of which would have been available if AT1 h= ad been passed around. Note that service A or the Client can also request a= downscoped token with [ C ] to call service C directly as well, and C does= n=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It doesn=E2= =80=99t have to do any special processing, doesn=E2=80=99t have to know wha= t=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a to= ken, I get another token based on this to call someone else=E2=80=9D. It=E2= =80=99s also analogous to the refresh token flow, but with access tokens go= ing in and out. I=E2=80=99ve deployed this setup several times in different= service deployments. Even though there is a performance hit in the additio= nal round trips (as Phil brought up in another thread), in these cases the = desire to have the tokens hold least privilege access rights (smallest set = of scopes per service) outweighed any performance hit (which was shown to b= e rather small in practice). What I want is for the token swap draft to define or use a mechanism that a= llows us to do this. I think we can do that pretty easily by adjusting the = token swap syntax and language, and explicitly calling out the semantic pro= cessing portion (the current core of the document) for what it is: a way fo= r a token issuer to communicate to a token service specific actions. At a h= igh level, the spec would be something like: 1. How to swap a token at an AS =C2=A0 1. Send a request to the token endpoint with a new grant type, and a= token (of any type/format/flavor) on the way in =C2=A0 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion =C2=A0 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as= semantics =C2=A0 2. What to do (as an AS/RS) with a JWT with act-as semantics =C2=A0 3. How to create a JWT with on-behalf-of semeantics =C2=A0 4. What to do with a JWT with on-behalf-of-semantics =C2=A0 5. How to possibly represent these semantics with something other th= an a JWT Section 2 uses the syntax from section 1. Other applications, like the one = I laid out above, can use the syntax from section 1 as well. This works for= structured, unstructured, self-generated, cross-domain, within-domain, and= other tokens. =E2=80=94 Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_2904038_671565861.1427397847434 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So why can't the access tokne s= imply be re-used as a refresh token?  Why would it need a new grant ty= pe at all?




On Thursday, March 26,= 2015 11:31 AM, Justin Richer <jricher@MIT.EDU> wrote:

As requested after last night= =E2=80=99s informal meeting, here is the token chaining use case that I wan= t to see represented in the token swap draft.


[ Client ]  -= >  [ A ] -> [ B ] -> [ C ]

An OAuth client gets an ac= cess token AT1, just like it always would, with scopes [A, B, C] in order t= o call service A, which requires all three scopes. Service A (an RS) accept= s this token since it has its scope, and then needs to call service B in tu= rn, which requires scopes [B, C]. It could just re-send the token it got in= , AT1, but that would give the downstream RS the ability to call services w= ith scope [ A ] and it should not be allowed to do that. To limit exposure,= service A calls a token swap at the AS to create AT2 with scopes [ B, C ],= effectively acting as an OAuth client requesting a downscoped token based = on AT1. Service A then acts as an OAuth client to call service B, now actin= g as an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service C, a= nd now B acts as a client, requesting AT3 with scope [ C ] based on AT2, an= d sending AT3 to service C. This prevents C from being able to call B or A,= both of which would have been available if AT1 had been passed around. Not= e that service A or the Client can also request a downscoped token with [ C= ] to call service C directly as well, and C doesn=E2=80=99t have to care h= ow it got there.


In other words, it lets the client software be = very, very dumb. It doesn=E2=80=99t have to do any special processing, does= n=E2=80=99t have to know what=E2=80=99s in the token, it just follows the r= ecipe of =E2=80=9CI got a token, I get another token based on this to call = someone else=E2=80=9D. It=E2=80=99s also analogous to the refresh token flo= w, but with access tokens going in and out. I=E2=80=99ve deployed this setu= p several times in different service deployments. Even though there is a pe= rformance hit in the additional round trips (as Phil brought up in another = thread), in these cases the desire to have the tokens hold least privilege = access rights (smallest set of scopes per service) outweighed any performan= ce hit (which was shown to be rather small in practice).

What I want= is for the token swap draft to define or use a mechanism that allows us to= do this. I think we can do that pretty easily by adjusting the token swap = syntax and language, and explicitly calling out the semantic processing por= tion (the current core of the document) for what it is: a way for a token i= ssuer to communicate to a token service specific actions. At a high level, = the spec would be something like:



1. How to swap a token at = an AS
  1. Send a request to the token endpoint with a new grant ty= pe, and a token (of any type/format/flavor) on the way in
  2. Get = back a new token in a token response
2. Communicating act as / on behalf= of semantics via a JWT assertion
  1. How to create (as an AS/RS/c= lient/other issuer) a JWT with act-as semantics
  2. What to do (as= an AS/RS) with a JWT with act-as semantics
  3. How to create a JW= T with on-behalf-of semeantics
  4. What to do with a JWT with on-b= ehalf-of-semantics
  5. How to possibly represent these semantics w= ith something other than a JWT



Section 2 uses the syntax fro= m section 1. Other applications, like the one I laid out above, can use the= syntax from section 1 as well. This works for structured, unstructured, se= lf-generated, cross-domain, within-domain, and other tokens.


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


------=_Part_2904038_671565861.1427397847434-- From nobody Thu Mar 26 12:44:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE7A1B2DEA for ; Thu, 26 Mar 2015 12:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hYzgAly32oUB for ; Thu, 26 Mar 2015 12:44:49 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B991A92AB for ; Thu, 26 Mar 2015 12:44:31 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-95-5514619d80d5 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 88.BC.03700.D9164155; Thu, 26 Mar 2015 15:44:29 -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 t2QJiSdh016664; Thu, 26 Mar 2015 15:44:29 -0400 Received: from [IPv6:2607:fb90:1c31:ca00:0:32:1b33:dd01] ([172.56.7.16]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2QJh8hH019032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 26 Mar 2015 15:44:25 -0400 Date: Thu, 26 Mar 2015 14:42:36 -0500 Message-ID: <9c1sdvnf558khwgomc9by3ys.1427398956170@email.android.com> Importance: normal From: Justin Richer To: Bill Mills , "" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_3904120130544920" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nrjs3USTU4NlKfYuTb1+xWXzrus7s wOSxZMlPJo9Zsw4zBTBFcdmkpOZklqUW6dslcGXMXniUteBHScWj6deYGhgfFHYxcnJICJhI rFv+hBXCFpO4cG89WxcjF4eQwGImiXOnXzFDOBsZJY7P+84K4Rxlkvh69wULSAuLgKrExoPH wWxhAX2J5dv7gIo4OHgF3CRWzy8FMTkFhCS6dkmAVLABVU9f08IEYosI+EhceHOPEcTmFRCU ODnzCdgUZoFQieZn/UwTGHlnIUnNQpKCsNUl/sy7xAxhK0pM6X7IPgtoG7OAmsSyViVk4QWM bKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCg9RFeQfjn4NKhxgFOBiVeHh/ 9AuHCrEmlhVX5h5ilORgUhLlPRYhEirEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhNc5FijHm5JY WZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBOz8BqFGwKDU9tSItM6cEIc3E wQkynAdoeBFIDW9xQWJucWY6RP4Uo6KUOG8fSEIAJJFRmgfXC0sirxjFgV4R5p0IUsUDTEBw 3a+ABjMBDT6XzwcyuCQRISXVwLjrvd8s8wcrv58Quu/0btVr4UMJH0rZ67e6tD7XiwzU2et7 c0v40nWcr0QbEj4syXvcnMIY7iJddubx1BOXk3+sWvfv/jTmQwvfzT0ropwqFpnMptx96KDO lrP8qlt0uQRjNvaLLaoX+7993sSJhfKrngbMvHibcY/hgcvspfbFD594qqdE6YgqsRRnJBpq MRcVJwIA631T5v0CAAA= Archived-At: Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:44:55 -0000 ----_com.android.email_3904120130544920 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKQmVjYXVzZSBtYW55IGltcGxlbWVudGF0aW9ucyAoaW5jbHVkaW5nIG1pbmUgd2hpY2gg ZG9lcyBzdXBwb3J0IG15IG9sZCB0b2tlbiBjaGFpbmluZyBkcmFmdCkgdHJlYXQgYWNjZXNzIHRv a2VucyBhbmQgcmVmcmVzaCB0b2tlbnMgc2VwYXJhdGVseSBpbiB0ZXJtcyBvZiBkYXRhIHN0b3Jl IGFuZCBzdHJ1Y3R1cmUuIEFkZGl0aW9uYWxseSwgdGhlIHJlZnJlc2ggdG9rZW4gaXMgdGllZCB0 byB0aGUgY2xpZW50IGFuZCBwcmVzZW50ZWQgYnkgdGhlIGNsaWVudC4gQnV0IGluIHRoaXMgY2Fz ZSBpdCdzIHNvbWVvbmUgZG93bnN0cmVhbSwgYW4gUlMsIHByZXNlbnRpbmcgdGhlIHRva2VuLiBT byB1bmxpa2UgYSByZWZyZXNoIHRva2VuIGJlaW5nIHByZXNlbnRlZCBieSB0aGUgb25lIGl0IHdh cyBpc3N1ZWQgdG8sIHRoaXMgdG9rZW4gaXMgYmVpbmcgcHJlc2VudGVkIGJ5IHNvbWVvbmUgaXQg d2FzIHByZXNlbnRlZCB0by7CoApUaGUgZmVlbGluZyBpcyBjbG9zZSwgYnV0IG5vdCBxdWl0ZSB0 aGUgc2FtZSBpbiBlaXRoZXIgZGV2ZWxvcG1lbnQgb3IgYXNzdW1wdGlvbnMuCi0tIEp1c3Rpbgov IFNlbnQgZnJvbSBteSBwaG9uZSAvCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0t CkZyb206IEJpbGwgTWlsbHMgPHdtaWxsc185MjEwNUB5YWhvby5jb20+IApEYXRlOiAwMy8yNi8y MDE1ICAyOjI0IFBNICAoR01ULTA2OjAwKSAKVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJATUlU LkVEVT4sICI8b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc+IApTdWJqZWN0OiBSZTog W09BVVRILVdHXSBUb2tlbiBDaGFpbmluZyBVc2UgQ2FzZSAKClNvIHdoeSBjYW4ndCB0aGUgYWNj ZXNzIHRva25lIHNpbXBseSBiZSByZS11c2VkIGFzIGEgcmVmcmVzaCB0b2tlbj8gwqBXaHkgd291 bGQgaXQgbmVlZCBhIG5ldyBncmFudCB0eXBlIGF0IGFsbD8KICAKCgogICAgIE9uIFRodXJzZGF5 LCBNYXJjaCAyNiwgMjAxNSAxMTozMSBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBNSVQuRURV PiB3cm90ZToKICAgIAoKIEFzIHJlcXVlc3RlZCBhZnRlciBsYXN0IG5pZ2h04oCZcyBpbmZvcm1h bCBtZWV0aW5nLCBoZXJlIGlzIHRoZSB0b2tlbiBjaGFpbmluZyB1c2UgY2FzZSB0aGF0IEkgd2Fu dCB0byBzZWUgcmVwcmVzZW50ZWQgaW4gdGhlIHRva2VuIHN3YXAgZHJhZnQuCgoKWyBDbGllbnQg XcKgIC0+wqAgIFsgQSBdIC0+IFsgQiBdIC0+IFsgQyBdCgpBbiBPQXV0aCBjbGllbnQgZ2V0cyBh biBhY2Nlc3MgdG9rZW4gQVQxLCBqdXN0IGxpa2UgaXQgYWx3YXlzIHdvdWxkLCB3aXRoIHNjb3Bl cyBbQSwgQiwgQ10gaW4gb3JkZXIgdG8gY2FsbCBzZXJ2aWNlIEEsIHdoaWNoIHJlcXVpcmVzIGFs bCB0aHJlZSBzY29wZXMuIFNlcnZpY2UgQSAoYW4gUlMpIGFjY2VwdHMgdGhpcyB0b2tlbiBzaW5j ZSBpdCBoYXMgaXRzIHNjb3BlLCBhbmQgdGhlbiBuZWVkcyB0byBjYWxsIHNlcnZpY2UgQiBpbiB0 dXJuLCB3aGljaCByZXF1aXJlcyBzY29wZXMgW0IsIENdLiBJdCBjb3VsZCBqdXN0IHJlLXNlbmQg dGhlIHRva2VuIGl0IGdvdCBpbiwgQVQxLCBidXQgdGhhdCB3b3VsZCBnaXZlIHRoZSBkb3duc3Ry ZWFtIFJTIHRoZSBhYmlsaXR5IHRvIGNhbGwgc2VydmljZXMgd2l0aCBzY29wZSBbIEEgXSBhbmQg aXQgc2hvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIGRvIHRoYXQuIFRvIGxpbWl0IGV4cG9zdXJlLCBz ZXJ2aWNlIEEgY2FsbHMgYSB0b2tlbiBzd2FwIGF0IHRoZSBBUyB0byBjcmVhdGUgQVQyIHdpdGgg c2NvcGVzIFsgQiwgQyBdLCBlZmZlY3RpdmVseSBhY3RpbmcgYXMgYW4gT0F1dGggY2xpZW50IHJl cXVlc3RpbmcgYSBkb3duc2NvcGVkIHRva2VuIGJhc2VkIG9uIEFUMS4gU2VydmljZSBBIHRoZW4g YWN0cyBhcyBhbiBPQXV0aCBjbGllbnQgdG8gY2FsbCBzZXJ2aWNlIEIsIG5vdyBhY3RpbmcgYXMg YW4gUlMgdG8gc2VydmljZSBB4oCZcyBjbGllbnQsIGFuZCBjYW4gZnVsZmlsbCB0aGUgcmVxdWVz dC4gQW5kIGl04oCZcyB0dXJ0bGVzIGFsbCB0aGUgd2F5IGRvd246IFNlcnZpY2UgQiBjYW4gYWxz byBjYWxsIHNlcnZpY2UgQywgYW5kIG5vdyBCIGFjdHMgYXMgYSBjbGllbnQsIHJlcXVlc3Rpbmcg QVQzIHdpdGggc2NvcGUgWyBDIF0gYmFzZWQgb24gQVQyLCBhbmQgc2VuZGluZyBBVDMgdG8gc2Vy dmljZSBDLiBUaGlzIHByZXZlbnRzIEMgZnJvbSBiZWluZyBhYmxlIHRvIGNhbGwgQiBvciBBLCBi b3RoIG9mIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiBhdmFpbGFibGUgaWYgQVQxIGhhZCBiZWVuIHBh c3NlZCBhcm91bmQuIE5vdGUgdGhhdCBzZXJ2aWNlIEEgb3IgdGhlIENsaWVudCBjYW4gYWxzbyBy ZXF1ZXN0IGEgZG93bnNjb3BlZCB0b2tlbiB3aXRoIFsgQyBdIHRvIGNhbGwgc2VydmljZSBDIGRp cmVjdGx5IGFzIHdlbGwsIGFuZCBDIGRvZXNu4oCZdCBoYXZlIHRvIGNhcmUgaG93IGl0IGdvdCB0 aGVyZS4KCgpJbiBvdGhlciB3b3JkcywgaXQgbGV0cyB0aGUgY2xpZW50IHNvZnR3YXJlIGJlIHZl cnksIHZlcnkgZHVtYi4gSXQgZG9lc27igJl0IGhhdmUgdG8gZG8gYW55IHNwZWNpYWwgcHJvY2Vz c2luZywgZG9lc27igJl0IGhhdmUgdG8ga25vdyB3aGF04oCZcyBpbiB0aGUgdG9rZW4sIGl0IGp1 c3QgZm9sbG93cyB0aGUgcmVjaXBlIG9mIOKAnEkgZ290IGEgdG9rZW4sIEkgZ2V0IGFub3RoZXIg dG9rZW4gYmFzZWQgb24gdGhpcyB0byBjYWxsIHNvbWVvbmUgZWxzZeKAnS4gSXTigJlzIGFsc28g YW5hbG9nb3VzIHRvIHRoZSByZWZyZXNoIHRva2VuIGZsb3csIGJ1dCB3aXRoIGFjY2VzcyB0b2tl bnMgZ29pbmcgaW4gYW5kIG91dC4gSeKAmXZlIGRlcGxveWVkIHRoaXMgc2V0dXAgc2V2ZXJhbCB0 aW1lcyBpbiBkaWZmZXJlbnQgc2VydmljZSBkZXBsb3ltZW50cy4gRXZlbiB0aG91Z2ggdGhlcmUg aXMgYSBwZXJmb3JtYW5jZSBoaXQgaW4gdGhlIGFkZGl0aW9uYWwgcm91bmQgdHJpcHMgKGFzIFBo aWwgYnJvdWdodCB1cCBpbiBhbm90aGVyIHRocmVhZCksIGluIHRoZXNlIGNhc2VzIHRoZSBkZXNp cmUgdG8gaGF2ZSB0aGUgdG9rZW5zIGhvbGQgbGVhc3QgcHJpdmlsZWdlIGFjY2VzcyByaWdodHMg KHNtYWxsZXN0IHNldCBvZiBzY29wZXMgcGVyIHNlcnZpY2UpIG91dHdlaWdoZWQgYW55IHBlcmZv cm1hbmNlIGhpdCAod2hpY2ggd2FzIHNob3duIHRvIGJlIHJhdGhlciBzbWFsbCBpbiBwcmFjdGlj ZSkuCgpXaGF0IEkgd2FudCBpcyBmb3IgdGhlIHRva2VuIHN3YXAgZHJhZnQgdG8gZGVmaW5lIG9y IHVzZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1cyB0byBkbyB0aGlzLiBJIHRoaW5rIHdlIGNh biBkbyB0aGF0IHByZXR0eSBlYXNpbHkgYnkgYWRqdXN0aW5nIHRoZSB0b2tlbiBzd2FwIHN5bnRh eCBhbmQgbGFuZ3VhZ2UsIGFuZCBleHBsaWNpdGx5IGNhbGxpbmcgb3V0IHRoZSBzZW1hbnRpYyBw cm9jZXNzaW5nIHBvcnRpb24gKHRoZSBjdXJyZW50IGNvcmUgb2YgdGhlIGRvY3VtZW50KSBmb3Ig d2hhdCBpdCBpczogYSB3YXkgZm9yIGEgdG9rZW4gaXNzdWVyIHRvIGNvbW11bmljYXRlIHRvIGEg dG9rZW4gc2VydmljZSBzcGVjaWZpYyBhY3Rpb25zLiBBdCBhIGhpZ2ggbGV2ZWwsIHRoZSBzcGVj IHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlOgoKCgoxLiBIb3cgdG8gc3dhcCBhIHRva2VuIGF0IGFu IEFTCsKgIDEuIFNlbmQgYSByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIGEgbmV3 IGdyYW50IHR5cGUsIGFuZCBhIHRva2VuIChvZiBhbnkgdHlwZS9mb3JtYXQvZmxhdm9yKSBvbiB0 aGUgd2F5IGluCsKgIDIuIEdldCBiYWNrIGEgbmV3IHRva2VuIGluIGEgdG9rZW4gcmVzcG9uc2UK Mi4gQ29tbXVuaWNhdGluZyBhY3QgYXMgLyBvbiBiZWhhbGYgb2Ygc2VtYW50aWNzIHZpYSBhIEpX VCBhc3NlcnRpb24KwqAgMS4gSG93IHRvIGNyZWF0ZSAoYXMgYW4gQVMvUlMvY2xpZW50L290aGVy IGlzc3VlcikgYSBKV1Qgd2l0aCBhY3QtYXMgc2VtYW50aWNzCsKgIDIuIFdoYXQgdG8gZG8gKGFz IGFuIEFTL1JTKSB3aXRoIGEgSldUIHdpdGggYWN0LWFzIHNlbWFudGljcwrCoCAzLiBIb3cgdG8g Y3JlYXRlIGEgSldUIHdpdGggb24tYmVoYWxmLW9mIHNlbWVhbnRpY3MKwqAgNC4gV2hhdCB0byBk byB3aXRoIGEgSldUIHdpdGggb24tYmVoYWxmLW9mLXNlbWFudGljcwrCoCA1LiBIb3cgdG8gcG9z c2libHkgcmVwcmVzZW50IHRoZXNlIHNlbWFudGljcyB3aXRoIHNvbWV0aGluZyBvdGhlciB0aGFu IGEgSldUCgoKClNlY3Rpb24gMiB1c2VzIHRoZSBzeW50YXggZnJvbSBzZWN0aW9uIDEuIE90aGVy IGFwcGxpY2F0aW9ucywgbGlrZSB0aGUgb25lIEkgbGFpZCBvdXQgYWJvdmUsIGNhbiB1c2UgdGhl IHN5bnRheCBmcm9tIHNlY3Rpb24gMSBhcyB3ZWxsLiBUaGlzIHdvcmtzIGZvciBzdHJ1Y3R1cmVk LCB1bnN0cnVjdHVyZWQsIHNlbGYtZ2VuZXJhdGVkLCBjcm9zcy1kb21haW4sIHdpdGhpbi1kb21h aW4sIGFuZCBvdGhlciB0b2tlbnMuCgoKIOKAlCBKdXN0aW4KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9BdXRoQGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKCgogICAgIA== ----_com.android.email_3904120130544920 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2PkJlY2F1c2UgbWFu eSBpbXBsZW1lbnRhdGlvbnMgKGluY2x1ZGluZyBtaW5lIHdoaWNoIGRvZXMgc3VwcG9ydCBteSBv bGQgdG9rZW4gY2hhaW5pbmcgZHJhZnQpIHRyZWF0IGFjY2VzcyB0b2tlbnMgYW5kIHJlZnJlc2gg dG9rZW5zIHNlcGFyYXRlbHkgaW4gdGVybXMgb2YgZGF0YSBzdG9yZSBhbmQgc3RydWN0dXJlLiBB ZGRpdGlvbmFsbHksIHRoZSByZWZyZXNoIHRva2VuIGlzIHRpZWQgdG8gdGhlIGNsaWVudCBhbmQg cHJlc2VudGVkIGJ5IHRoZSBjbGllbnQuIEJ1dCBpbiB0aGlzIGNhc2UgaXQncyBzb21lb25lIGRv d25zdHJlYW0sIGFuIFJTLCBwcmVzZW50aW5nIHRoZSB0b2tlbi4gU28gdW5saWtlIGEgcmVmcmVz aCB0b2tlbiBiZWluZyBwcmVzZW50ZWQgYnkgdGhlIG9uZSBpdCB3YXMgaXNzdWVkIHRvLCB0aGlz IHRva2VuIGlzIGJlaW5nIHByZXNlbnRlZCBieSBzb21lb25lIGl0IHdhcyBwcmVzZW50ZWQgdG8u Jm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgZmVlbGluZyBpcyBjbG9zZSwgYnV0 IG5vdCBxdWl0ZSB0aGUgc2FtZSBpbiBlaXRoZXIgZGV2ZWxvcG1lbnQgb3IgYXNzdW1wdGlvbnMu PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0 eWxlPSJmb250LXNpemU6OXB4Ij48ZGl2IHN0eWxlPSJmb250LXNpemU6IDlweDsgIj4tLSBKdXN0 aW48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6IDlweDsgIj48YnI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1zaXplOiA5cHg7ICI+LyBTZW50IGZyb20gbXkgcGhvbmUgLzwvZGl2PjwvZGl2Pjxk aXY+PC9kaXY+PC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0t PGJyPkZyb206IEJpbGwgTWlsbHMgJmx0O3dtaWxsc185MjEwNUB5YWhvby5jb20mZ3Q7IDxicj5E YXRlOiAwMy8yNi8yMDE1ICAyOjI0IFBNICAoR01ULTA2OjAwKSA8YnI+VG86IEp1c3RpbiBSaWNo ZXIgJmx0O2pyaWNoZXJATUlULkVEVSZndDssICImbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7IiAmbHQ7 b2F1dGhAaWV0Zi5vcmcmZ3Q7IDxicj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBUb2tlbiBDaGFp bmluZyBVc2UgQ2FzZSA8YnI+PGJyPjxkaXYgc3R5bGU9ImNvbG9yOiMwMDA7IGJhY2tncm91bmQt Y29sb3I6I2ZmZjsgZm9udC1mYW1pbHk6SGVsdmV0aWNhTmV1ZSwgSGVsdmV0aWNhIE5ldWUsIEhl bHZldGljYSwgQXJpYWwsIEx1Y2lkYSBHcmFuZGUsIHNhbnMtc2VyaWY7Zm9udC1zaXplOjEycHgi PjxkaXYgZGlyPSJsdHIiIGlkPSJ5dWlfM18xNl8wXzFfMTQyNzM0MzU4MTM5Ml8xNTM3NjEiPjxz cGFuIGlkPSJ5dWlfM18xNl8wXzFfMTQyNzM0MzU4MTM5Ml8xNTM3NjAiPlNvIHdoeSBjYW4ndCB0 aGUgYWNjZXNzIHRva25lIHNpbXBseSBiZSByZS11c2VkIGFzIGEgcmVmcmVzaCB0b2tlbj8gJm5i c3A7V2h5IHdvdWxkIGl0IG5lZWQgYSBuZXcgZ3JhbnQgdHlwZSBhdCBhbGw/PC9zcGFuPjwvZGl2 PjxkaXYgZGlyPSJsdHIiIGlkPSJ5dWlfM18xNl8wXzFfMTQyNzM0MzU4MTM5Ml8xNTM3NjIiPjxz cGFuPjxicj48L3NwYW4+PC9kaXY+ICA8YnI+PGRpdiBjbGFzcz0icXRkU2VwYXJhdGVCUiI+PGJy Pjxicj48L2Rpdj48ZGl2IGNsYXNzPSJ5YWhvb19xdW90ZWQiIHN0eWxlPSJkaXNwbGF5OiBibG9j azsiPiA8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhTmV1ZSwgSGVsdmV0aWNhIE5l dWUsIEhlbHZldGljYSwgQXJpYWwsIEx1Y2lkYSBHcmFuZGUsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTJweDsiPiA8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhTmV1ZSwgSGVsdmV0 aWNhIE5ldWUsIEhlbHZldGljYSwgQXJpYWwsIEx1Y2lkYSBHcmFuZGUsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTZweDsiPiA8ZGl2IGRpcj0ibHRyIj4gPGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJp YWwiPiBPbiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTE6MzEgQU0sIEp1c3RpbiBSaWNoZXIg Jmx0O2pyaWNoZXJATUlULkVEVSZndDsgd3JvdGU6PGJyPiA8L2ZvbnQ+IDwvZGl2PiAgPGJyPjxi cj4gPGRpdiBjbGFzcz0ieV9tc2dfY29udGFpbmVyIj5BcyByZXF1ZXN0ZWQgYWZ0ZXIgbGFzdCBu aWdodOKAmXMgaW5mb3JtYWwgbWVldGluZywgaGVyZSBpcyB0aGUgdG9rZW4gY2hhaW5pbmcgdXNl IGNhc2UgdGhhdCBJIHdhbnQgdG8gc2VlIHJlcHJlc2VudGVkIGluIHRoZSB0b2tlbiBzd2FwIGRy YWZ0Ljxicj48YnI+PGJyPlsgQ2xpZW50IF0mbmJzcDsgLSZndDsmbmJzcDsgIFsgQSBdIC0mZ3Q7 IFsgQiBdIC0mZ3Q7IFsgQyBdPGJyPjxicj5BbiBPQXV0aCBjbGllbnQgZ2V0cyBhbiBhY2Nlc3Mg dG9rZW4gQVQxLCBqdXN0IGxpa2UgaXQgYWx3YXlzIHdvdWxkLCB3aXRoIHNjb3BlcyBbQSwgQiwg Q10gaW4gb3JkZXIgdG8gY2FsbCBzZXJ2aWNlIEEsIHdoaWNoIHJlcXVpcmVzIGFsbCB0aHJlZSBz Y29wZXMuIFNlcnZpY2UgQSAoYW4gUlMpIGFjY2VwdHMgdGhpcyB0b2tlbiBzaW5jZSBpdCBoYXMg aXRzIHNjb3BlLCBhbmQgdGhlbiBuZWVkcyB0byBjYWxsIHNlcnZpY2UgQiBpbiB0dXJuLCB3aGlj aCByZXF1aXJlcyBzY29wZXMgW0IsIENdLiBJdCBjb3VsZCBqdXN0IHJlLXNlbmQgdGhlIHRva2Vu IGl0IGdvdCBpbiwgQVQxLCBidXQgdGhhdCB3b3VsZCBnaXZlIHRoZSBkb3duc3RyZWFtIFJTIHRo ZSBhYmlsaXR5IHRvIGNhbGwgc2VydmljZXMgd2l0aCBzY29wZSBbIEEgXSBhbmQgaXQgc2hvdWxk IG5vdCBiZSBhbGxvd2VkIHRvIGRvIHRoYXQuIFRvIGxpbWl0IGV4cG9zdXJlLCBzZXJ2aWNlIEEg Y2FsbHMgYSB0b2tlbiBzd2FwIGF0IHRoZSBBUyB0byBjcmVhdGUgQVQyIHdpdGggc2NvcGVzIFsg QiwgQyBdLCBlZmZlY3RpdmVseSBhY3RpbmcgYXMgYW4gT0F1dGggY2xpZW50IHJlcXVlc3Rpbmcg YSBkb3duc2NvcGVkIHRva2VuIGJhc2VkIG9uIEFUMS4gU2VydmljZSBBIHRoZW4gYWN0cyBhcyBh biBPQXV0aCBjbGllbnQgdG8gY2FsbCBzZXJ2aWNlIEIsIG5vdyBhY3RpbmcgYXMgYW4gUlMgdG8g c2VydmljZSBB4oCZcyBjbGllbnQsIGFuZCBjYW4gZnVsZmlsbCB0aGUgcmVxdWVzdC4gQW5kIGl0 4oCZcyB0dXJ0bGVzIGFsbCB0aGUgd2F5IGRvd246IFNlcnZpY2UgQiBjYW4gYWxzbyBjYWxsIHNl cnZpY2UgQywgYW5kIG5vdyBCIGFjdHMgYXMgYSBjbGllbnQsIHJlcXVlc3RpbmcgQVQzIHdpdGgg c2NvcGUgWyBDIF0gYmFzZWQgb24gQVQyLCBhbmQgc2VuZGluZyBBVDMgdG8gc2VydmljZSBDLiBU aGlzIHByZXZlbnRzIEMgZnJvbSBiZWluZyBhYmxlIHRvIGNhbGwgQiBvciBBLCBib3RoIG9mIHdo aWNoIHdvdWxkIGhhdmUgYmVlbiBhdmFpbGFibGUgaWYgQVQxIGhhZCBiZWVuIHBhc3NlZCBhcm91 bmQuIE5vdGUgdGhhdCBzZXJ2aWNlIEEgb3IgdGhlIENsaWVudCBjYW4gYWxzbyByZXF1ZXN0IGEg ZG93bnNjb3BlZCB0b2tlbiB3aXRoIFsgQyBdIHRvIGNhbGwgc2VydmljZSBDIGRpcmVjdGx5IGFz IHdlbGwsIGFuZCBDIGRvZXNu4oCZdCBoYXZlIHRvIGNhcmUgaG93IGl0IGdvdCB0aGVyZS48YnI+ PGJyPjxicj5JbiBvdGhlciB3b3JkcywgaXQgbGV0cyB0aGUgY2xpZW50IHNvZnR3YXJlIGJlIHZl cnksIHZlcnkgZHVtYi4gSXQgZG9lc27igJl0IGhhdmUgdG8gZG8gYW55IHNwZWNpYWwgcHJvY2Vz c2luZywgZG9lc27igJl0IGhhdmUgdG8ga25vdyB3aGF04oCZcyBpbiB0aGUgdG9rZW4sIGl0IGp1 c3QgZm9sbG93cyB0aGUgcmVjaXBlIG9mIOKAnEkgZ290IGEgdG9rZW4sIEkgZ2V0IGFub3RoZXIg dG9rZW4gYmFzZWQgb24gdGhpcyB0byBjYWxsIHNvbWVvbmUgZWxzZeKAnS4gSXTigJlzIGFsc28g YW5hbG9nb3VzIHRvIHRoZSByZWZyZXNoIHRva2VuIGZsb3csIGJ1dCB3aXRoIGFjY2VzcyB0b2tl bnMgZ29pbmcgaW4gYW5kIG91dC4gSeKAmXZlIGRlcGxveWVkIHRoaXMgc2V0dXAgc2V2ZXJhbCB0 aW1lcyBpbiBkaWZmZXJlbnQgc2VydmljZSBkZXBsb3ltZW50cy4gRXZlbiB0aG91Z2ggdGhlcmUg aXMgYSBwZXJmb3JtYW5jZSBoaXQgaW4gdGhlIGFkZGl0aW9uYWwgcm91bmQgdHJpcHMgKGFzIFBo aWwgYnJvdWdodCB1cCBpbiBhbm90aGVyIHRocmVhZCksIGluIHRoZXNlIGNhc2VzIHRoZSBkZXNp cmUgdG8gaGF2ZSB0aGUgdG9rZW5zIGhvbGQgbGVhc3QgcHJpdmlsZWdlIGFjY2VzcyByaWdodHMg KHNtYWxsZXN0IHNldCBvZiBzY29wZXMgcGVyIHNlcnZpY2UpIG91dHdlaWdoZWQgYW55IHBlcmZv cm1hbmNlIGhpdCAod2hpY2ggd2FzIHNob3duIHRvIGJlIHJhdGhlciBzbWFsbCBpbiBwcmFjdGlj ZSkuPGJyPjxicj5XaGF0IEkgd2FudCBpcyBmb3IgdGhlIHRva2VuIHN3YXAgZHJhZnQgdG8gZGVm aW5lIG9yIHVzZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1cyB0byBkbyB0aGlzLiBJIHRoaW5r IHdlIGNhbiBkbyB0aGF0IHByZXR0eSBlYXNpbHkgYnkgYWRqdXN0aW5nIHRoZSB0b2tlbiBzd2Fw IHN5bnRheCBhbmQgbGFuZ3VhZ2UsIGFuZCBleHBsaWNpdGx5IGNhbGxpbmcgb3V0IHRoZSBzZW1h bnRpYyBwcm9jZXNzaW5nIHBvcnRpb24gKHRoZSBjdXJyZW50IGNvcmUgb2YgdGhlIGRvY3VtZW50 KSBmb3Igd2hhdCBpdCBpczogYSB3YXkgZm9yIGEgdG9rZW4gaXNzdWVyIHRvIGNvbW11bmljYXRl IHRvIGEgdG9rZW4gc2VydmljZSBzcGVjaWZpYyBhY3Rpb25zLiBBdCBhIGhpZ2ggbGV2ZWwsIHRo ZSBzcGVjIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlOjxicj48YnI+PGJyPjxicj4xLiBIb3cgdG8g c3dhcCBhIHRva2VuIGF0IGFuIEFTPGJyPiZuYnNwOyAxLiBTZW5kIGEgcmVxdWVzdCB0byB0aGUg dG9rZW4gZW5kcG9pbnQgd2l0aCBhIG5ldyBncmFudCB0eXBlLCBhbmQgYSB0b2tlbiAob2YgYW55 IHR5cGUvZm9ybWF0L2ZsYXZvcikgb24gdGhlIHdheSBpbjxicj4mbmJzcDsgMi4gR2V0IGJhY2sg YSBuZXcgdG9rZW4gaW4gYSB0b2tlbiByZXNwb25zZTxicj4yLiBDb21tdW5pY2F0aW5nIGFjdCBh cyAvIG9uIGJlaGFsZiBvZiBzZW1hbnRpY3MgdmlhIGEgSldUIGFzc2VydGlvbjxicj4mbmJzcDsg MS4gSG93IHRvIGNyZWF0ZSAoYXMgYW4gQVMvUlMvY2xpZW50L290aGVyIGlzc3VlcikgYSBKV1Qg d2l0aCBhY3QtYXMgc2VtYW50aWNzPGJyPiZuYnNwOyAyLiBXaGF0IHRvIGRvIChhcyBhbiBBUy9S Uykgd2l0aCBhIEpXVCB3aXRoIGFjdC1hcyBzZW1hbnRpY3M8YnI+Jm5ic3A7IDMuIEhvdyB0byBj cmVhdGUgYSBKV1Qgd2l0aCBvbi1iZWhhbGYtb2Ygc2VtZWFudGljczxicj4mbmJzcDsgNC4gV2hh dCB0byBkbyB3aXRoIGEgSldUIHdpdGggb24tYmVoYWxmLW9mLXNlbWFudGljczxicj4mbmJzcDsg NS4gSG93IHRvIHBvc3NpYmx5IHJlcHJlc2VudCB0aGVzZSBzZW1hbnRpY3Mgd2l0aCBzb21ldGhp bmcgb3RoZXIgdGhhbiBhIEpXVDxicj48YnI+PGJyPjxicj5TZWN0aW9uIDIgdXNlcyB0aGUgc3lu dGF4IGZyb20gc2VjdGlvbiAxLiBPdGhlciBhcHBsaWNhdGlvbnMsIGxpa2UgdGhlIG9uZSBJIGxh aWQgb3V0IGFib3ZlLCBjYW4gdXNlIHRoZSBzeW50YXggZnJvbSBzZWN0aW9uIDEgYXMgd2VsbC4g VGhpcyB3b3JrcyBmb3Igc3RydWN0dXJlZCwgdW5zdHJ1Y3R1cmVkLCBzZWxmLWdlbmVyYXRlZCwg Y3Jvc3MtZG9tYWluLCB3aXRoaW4tZG9tYWluLCBhbmQgb3RoZXIgdG9rZW5zLjxicj48YnI+PGJy PiDigJQgSnVzdGluPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSB5bWFpbHRvPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxicj48YnI+PGJyPjwvZGl2PiAgPC9kaXY+IDwvZGl2PiAgPC9kaXY+PC9kaXY+PC9i b2R5PjwvaHRtbD4= ----_com.android.email_3904120130544920-- From nobody Thu Mar 26 12:53:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18D31B2B87 for ; Thu, 26 Mar 2015 12:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XS1ks4TIgP3a for ; Thu, 26 Mar 2015 12:53:39 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28641A00E0 for ; Thu, 26 Mar 2015 12:53:39 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2QJrbQ3031205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Mar 2015 19:53:38 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t2QJrbcD004406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2015 19:53:37 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2QJrb9m031415; Thu, 26 Mar 2015 19:53:37 GMT Received: from [172.16.90.223] (/199.227.110.154) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Mar 2015 12:53:36 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: Date: Thu, 26 Mar 2015 14:53:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2574ED86-AC5F-4140-9A6D-0D4DEA0A2690@oracle.com> References: To: Justin Richer X-Mailer: Apple Mail (2.2070.6) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:53:41 -0000 What if A calls be with it=E2=80=99s own authorization token (server = token ST1) and passes AT1 in another header e.g. on-behalf-of. You save a call and can still check the scope downstream. Further, = service B and C can each check whether ST1 and ST2 had the right to = wield AT1 even when AT1=E2=80=99s POP proof is a proof of the external = client. The only reason I can think to call the AS is if there is some dynamic = condition that might cause an AS to reject the swap. If AT1 is valid, I = can=E2=80=99t think of another reason why the answer isn=E2=80=99t = already YES for all calls. If its no, its likely a permanent = configuration problem not a dynamic decision. In other words, B always = expects A to call it on behalf of some one. Likewise, C is always = expecting B. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 26, 2015, at 1:31 PM, Justin Richer wrote: >=20 > As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap = draft. >=20 >=20 > [ Client ] -> [ A ] -> [ B ] -> [ C ] >=20 > An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. >=20 >=20 > In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of =E2=80=9C= I got a token, I get another token based on this to call someone = else=E2=80=9D. It=E2=80=99s also analogous to the refresh token flow, = but with access tokens going in and out. I=E2=80=99ve deployed this = setup several times in different service deployments. Even though there = is a performance hit in the additional round trips (as Phil brought up = in another thread), in these cases the desire to have the tokens hold = least privilege access rights (smallest set of scopes per service) = outweighed any performance hit (which was shown to be rather small in = practice). >=20 > What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for = what it is: a way for a token issuer to communicate to a token service = specific actions. At a high level, the spec would be something like: >=20 >=20 >=20 > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as = semantics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other = than a JWT >=20 >=20 >=20 > Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This = works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens. >=20 >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Mar 26 13:13:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FD81B2E39 for ; Thu, 26 Mar 2015 13:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 8_9fSewEPXjF for ; Thu, 26 Mar 2015 13:13:28 -0700 (PDT) Received: from nm32-vm4.bullet.mail.bf1.yahoo.com (nm32-vm4.bullet.mail.bf1.yahoo.com [72.30.239.140]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F4B1B2E36 for ; Thu, 26 Mar 2015 13:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427400807; bh=zBfnBfxEaqrCxYgQV5h08cS0yoqwsFSW8saztNPRANo=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=FH112rIQEWcEViXDWxQwE+XKVC/ftb/OyILVrEcxzWecUZ9znfENMI1sred0wwqlf8nVMmRYL9aWBQutLE/mqN+S8I8mRs8gwKwrTwg8w1QeSLUB8gOndL/gVfVdtejREPYpKVaWg0++RGD5FeLSpXRZe9Igc50mtvHvhPAtnNB5kJHePyIt4BhDAOnEo7g0YaQg+VJmKeB8W2V8G7hAt/UUcMcxQYb8N3KClY9lGxQcnusw4528O+eBJXZxAPi38+oJ1E5k8KYaJ7SfAzTspvcARGWKi+fee26rz+BTIERg2xj9py7+J0jrWFgcEs0JhOmXA+MtW0YZ48vAWgNW8w== Received: from [66.196.81.170] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 20:13:27 -0000 Received: from [98.139.212.216] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 20:13:27 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 20:13:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 613317.64682.bm@omp1025.mail.bf1.yahoo.com X-YMail-OSG: ExkaIU8VM1lSKiKQRSPfCZ1Dvny0i.q2tfXerCeKGCIuzdpLne.ZLpXT1Ookukf EnaIsLC_RpcYiZGs7Rp6enM5WCYz6OhD305NhYAAkmI_SW_CqusviBWkVMZhbBqJ.E7htilreT8D wnqimsai5inccLi3AMtZWQpMl56irg50PH7TqL2N2aU6EPpW2n7ywCZmnzOEu_CkCiNq9M87ww7R oXT62gUvOdRpjOLaW2CcSRraHUn4m5BUX0Y.Q6iDsSjdPvleNFdFSTte5WUgb.S86S0i2dxdtd8v wDW9n3_a.d5iFyBC3zqPqJnRjZerbvzc78uEi0WeWSoJ.nSIcqIz3T1uC0i.JRotUnzEuOhLUcnM QIZJDYlkjJtjgQ7keEuypzeWt9PXCAAOLhNAcDeksxr3D5qCsIpTR.NJgVRb6GsFOCBN8qnm6Lvy v18z2zSaVSDEfbZomv614d.vqen.VEXsrAekCWxeyBetSY0k3j9JAGxRi6ebgnalpp8x2kWTd6f1 nMuw9Jyz5wPOZ1ZkFqsiW0CJ6TSiw9TIQSVMS_yfI Received: by 76.13.26.159; Thu, 26 Mar 2015 20:13:27 +0000 Date: Thu, 26 Mar 2015 20:13:26 +0000 (UTC) From: Bill Mills To: Justin Richer , "" Message-ID: <583669811.2960904.1427400806728.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <9c1sdvnf558khwgomc9by3ys.1427398956170@email.android.com> References: <9c1sdvnf558khwgomc9by3ys.1427398956170@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2960903_1937475469.1427400806723" Archived-At: Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:13:31 -0000 ------=_Part_2960903_1937475469.1427400806723 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable By definition an access token is becoming a form of refresh token. =C2=A0 = =C2=A0The "because my implementation didn't do it that way" isn't convincin= g me.=20 On Thursday, March 26, 2015 12:44 PM, Justin Richer = wrote: =20 Because many implementations (including mine which does support my old to= ken chaining draft) treat access tokens and refresh tokens separately in te= rms of data store and structure. Additionally, the refresh token is tied to= the client and presented by the client. But in this case it's someone down= stream, an RS, presenting the token. So unlike a refresh token being presen= ted by the one it was issued to, this token is being presented by someone i= t was presented to.=C2=A0 The feeling is close, but not quite the same in either development or assum= ptions. -- Justin / Sent from my phone / -------- Original message -------- From: Bill Mills =20 Date: 03/26/2015 2:24 PM (GMT-06:00)=20 To: Justin Richer , "" =20 Subject: Re: [OAUTH-WG] Token Chaining Use Case=20 So why can't the access tokne simply be re-used as a refresh token? =C2=A0W= hy would it need a new grant type at all? =20 On Thursday, March 26, 2015 11:31 AM, Justin Richer = wrote: =20 As requested after last night=E2=80=99s informal meeting, here is the toke= n chaining use case that I want to see represented in the token swap draft. [ Client ]=C2=A0 ->=C2=A0 [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, with s= copes [A, B, C] in order to call service A, which requires all three scopes= . Service A (an RS) accepts this token since it has its scope, and then nee= ds to call service B in turn, which requires scopes [B, C]. It could just r= e-send the token it got in, AT1, but that would give the downstream RS the = ability to call services with scope [ A ] and it should not be allowed to d= o that. To limit exposure, service A calls a token swap at the AS to create= AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting= a downscoped token based on AT1. Service A then acts as an OAuth client to= call service B, now acting as an RS to service A=E2=80=99s client, and can= fulfill the request. And it=E2=80=99s turtles all the way down: Service B = can also call service C, and now B acts as a client, requesting AT3 with sc= ope [ C ] based on AT2, and sending AT3 to service C. This prevents C from = being able to call B or A, both of which would have been available if AT1 h= ad been passed around. Note that service A or the Client can also request a= downscoped token with [ C ] to call service C directly as well, and C does= n=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It doesn=E2= =80=99t have to do any special processing, doesn=E2=80=99t have to know wha= t=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a to= ken, I get another token based on this to call someone else=E2=80=9D. It=E2= =80=99s also analogous to the refresh token flow, but with access tokens go= ing in and out. I=E2=80=99ve deployed this setup several times in different= service deployments. Even though there is a performance hit in the additio= nal round trips (as Phil brought up in another thread), in these cases the = desire to have the tokens hold least privilege access rights (smallest set = of scopes per service) outweighed any performance hit (which was shown to b= e rather small in practice). What I want is for the token swap draft to define or use a mechanism that a= llows us to do this. I think we can do that pretty easily by adjusting the = token swap syntax and language, and explicitly calling out the semantic pro= cessing portion (the current core of the document) for what it is: a way fo= r a token issuer to communicate to a token service specific actions. At a h= igh level, the spec would be something like: 1. How to swap a token at an AS =C2=A0 1. Send a request to the token endpoint with a new grant type, and a= token (of any type/format/flavor) on the way in =C2=A0 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion =C2=A0 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as= semantics =C2=A0 2. What to do (as an AS/RS) with a JWT with act-as semantics =C2=A0 3. How to create a JWT with on-behalf-of semeantics =C2=A0 4. What to do with a JWT with on-behalf-of-semantics =C2=A0 5. How to possibly represent these semantics with something other th= an a JWT Section 2 uses the syntax from section 1. Other applications, like the one = I laid out above, can use the syntax from section 1 as well. This works for= structured, unstructured, self-generated, cross-domain, within-domain, and= other tokens. =E2=80=94 Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_2960903_1937475469.1427400806723 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By = definition an access token is becoming a form of refresh token.   &nbs= p;The "because my implementation didn't do it that way" isn't convincing me= .



On Thursday, March 26,= 2015 12:44 PM, Justin Richer <jricher@mit.edu> wrote:

=20
Because many implementations = (including mine which does support my old token chaining draft) treat acces= s tokens and refresh tokens separately in terms of data store and structure= . Additionally, the refresh token is tied to the client and presented by th= e client. But in this case it's someone downstream, an RS, presenting the t= oken. So unlike a refresh token being presented by the one it was issued to= , this token is being presented by someone it was presented to. 
=

The feeling is close, but not quite the = same in either development or assumptions.

-- Justin

/ Sent from my pho= ne /


----= ---- Original message --------
From: Bill Mills <wmill= s_92105@yahoo.com>
Date: 03/26/2015 2:24 PM (GMT-06= :00)
To: Justin Richer <jricher@MIT.EDU>, "<oau= th@ietf.org>" <oauth@ietf.org>
Subject: Re: [OA= UTH-WG] Token Chaining Use Case

So why can't the access tok= ne simply be re-used as a refresh token?  Why would it need a new gran= t type at all?




= On Thursday, March 26, 2015 11:31 AM, Justin Richer <jricher@MIT.EDU>= wrote:


As requested after last = night=E2=80=99s informal meeting, here is the token chaining use case that = I want to see represented in the token swap draft.


[ Client ]  ->  [ A ] -> [= B ] -> [ C ]

An OAuth client gets = an access token AT1, just like it always would, with scopes [A, B, C] in or= der to call service A, which requires all three scopes. Service A (an RS) a= ccepts this token since it has its scope, and then needs to call service B = in turn, which requires scopes [B, C]. It could just re-send the token it g= ot in, AT1, but that would give the downstream RS the ability to call servi= ces with scope [ A ] and it should not be allowed to do that. To limit expo= sure, service A calls a token swap at the AS to create AT2 with scopes [ B,= C ], effectively acting as an OAuth client requesting a downscoped token b= ased on AT1. Service A then acts as an OAuth client to call service B, now = acting as an RS to service A=E2=80=99s client, and can fulfill the request.= And it=E2=80=99s turtles all the way down: Service B can also call service= C, and now B acts as a client, requesting AT3 with scope [ C ] based on AT= 2, and sending AT3 to service C. This prevents C from being able to call B = or A, both of which would have been available if AT1 had been passed around= . Note that service A or the Client can also request a downscoped token wit= h [ C ] to call service C directly as well, and C doesn=E2=80=99t have to c= are how it got there.


In other words, it lets the client software be very, very dumb. It doesn= =E2=80=99t have to do any special processing, doesn=E2=80=99t have to know = what=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a= token, I get another token based on this to call someone else=E2=80=9D. It= =E2=80=99s also analogous to the refresh token flow, but with access tokens= going in and out. I=E2=80=99ve deployed this setup several times in differ= ent service deployments. Even though there is a performance hit in the addi= tional round trips (as Phil brought up in another thread), in these cases t= he desire to have the tokens hold least privilege access rights (smallest s= et of scopes per service) outweighed any performance hit (which was shown t= o be rather small in practice).

What I= want is for the token swap draft to define or use a mechanism that allows = us to do this. I think we can do that pretty easily by adjusting the token = swap syntax and language, and explicitly calling out the semantic processin= g portion (the current core of the document) for what it is: a way for a to= ken issuer to communicate to a token service specific actions. At a high le= vel, the spec would be something like:



1. How to swap a token at an AS
  1. Send a request to the token endpoint with a new gra= nt type, and a token (of any type/format/flavor) on the way in
  2. Get back a new token in a token response
= 2. Communicating act as / on behalf of semantics via a JWT assertion
  1. How to create (as an AS/RS/client/other issuer) a JWT= with act-as semantics
  2. What to do (as an AS/RS)= with a JWT with act-as semantics
  3. How to create= a JWT with on-behalf-of semeantics
  4. What to do = with a JWT with on-behalf-of-semantics
  5. How to p= ossibly represent these semantics with something other than a JWT



Section = 2 uses the syntax from section 1. Other applications, like the one I laid o= ut above, can use the syntax from section 1 as well. This works for structu= red, unstructured, self-generated, cross-domain, within-domain, and other t= okens.


=E2=80=94 J= ustin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




------=_Part_2960903_1937475469.1427400806723-- From nobody Thu Mar 26 13:15:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582A41B2E58 for ; Thu, 26 Mar 2015 13:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Z4qmzXGhFD-s for ; Thu, 26 Mar 2015 13:15:43 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C461B2E39 for ; Thu, 26 Mar 2015 13:15:43 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-df-551468edd8bd Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8E.20.03678.DE864155; Thu, 26 Mar 2015 16:15:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t2QKFa9E007045; Thu, 26 Mar 2015 16:15:37 -0400 Received: from dhcp-b47c.meeting.ietf.org (dhcp-b47c.meeting.ietf.org [31.133.180.124]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2QKFXts029837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Mar 2015 16:15:35 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2E2FD031-6213-4A06-9039-FBD98CEA9781"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <2574ED86-AC5F-4140-9A6D-0D4DEA0A2690@oracle.com> Date: Thu, 26 Mar 2015 15:15:33 -0500 Message-Id: <91BF31B4-BDE5-4912-BFBE-C9FD8EB07A96@mit.edu> References: <2574ED86-AC5F-4140-9A6D-0D4DEA0A2690@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsUixG6novs2QyTU4H+jmcXJt6/YLBbMb2R3 YPJYsuQnk8fHp7dYApiiuGxSUnMyy1KL9O0SuDIW/VQsuGJS8WzXApYGxudaXYycHBICJhJf /7QzQdhiEhfurWfrYuTiEBJYzCTx8tkFKGcjo8S3y/9ZIZwrTBKXLr1lA2kRFtCXWL69jxXE 5hUwkJh76gvYKGaBKYwS504qQoyVkmh6fYwRxGYTUJWYvqYFrIZTwE5iyftrzF2MHBwsQPHd /TUgJrOAukT7SReIiVYSy/qXs4OEhQRyJL5eAmsUEVCR+Hb1OiNIWEJAXqJnU/oERsFZSE6Y heQECFtbYtnC18wQtqbE/u7lLBC2vMT2t3Og4pYSi2fegIrbStzqWwA1x07i0bRFrAsYOVYx yqbkVunmJmbmFKcm6xYnJ+blpRbpWujlZpbopaaUbmIER4yL6g7GCYeUDjEKcDAq8fD+7BcO FWJNLCuuzD3EKMnBpCTKy5QoEirEl5SfUpmRWJwRX1Sak1p8iFEFaNejDasvMEqx5OXnpSqJ 8DrHAtXxpiRWVqUW5cOUSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgrUwHahQsSk1P rUjLzClBSDNxcB5ilODgARq+DaSGt7ggMbc4Mx0if4pRUUqc9wJIQgAkkVGaB9cLS3SvGMWB 3hLmlQKmPSEeYJKE634FNJgJaPC5fD6QwSWJCCmpBsZdOhNqXJccDFP2zr62O6i/bHrtz5/s 8SH1DFmzU/conJr0nz3tiiTjp6PydneTsrRsvgXdcbqfMPX7Du4t/6oOrTn4MaLCMPLCTafF XefX5970CLy+7+OqqeyCVycJ3Za2aP1wPFhQ7ly8f0Qud9nj1ad///tWvEBAMG7TrkfnD6iU r/vh+DFGiaU4I9FQi7moOBEA17CxCk8DAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:15:46 -0000 --Apple-Mail=_2E2FD031-6213-4A06-9039-FBD98CEA9781 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Your service layout will determine whether or not each bit calls the = same AS that issued the original token, since you can easily do it = across boundaries if your AS takes in cross domain tokens. That=E2=80=99s = another benefit of having it be a generic token swap, you can build it = out using the same mechanism and get both behaviors. The AS could reject the swap for any number of conditions: wrong client = asked, token is expired, scopes don=E2=80=99t align, bad token, etc. You can always optimize your system such that you just send a = high-powered token down the chain, in which case you=E2=80=99re not = using token swapping. This is not for those cases, obviously. This is = for the cases when you *are* doing token swapping and usually = downscoping the privileges. =E2=80=94 Justin > On Mar 26, 2015, at 2:53 PM, Phil Hunt wrote: >=20 > What if A calls be with it=E2=80=99s own authorization token (server = token ST1) and passes AT1 in another header e.g. on-behalf-of. >=20 > You save a call and can still check the scope downstream. Further, = service B and C can each check whether ST1 and ST2 had the right to = wield AT1 even when AT1=E2=80=99s POP proof is a proof of the external = client. >=20 > The only reason I can think to call the AS is if there is some dynamic = condition that might cause an AS to reject the swap. If AT1 is valid, I = can=E2=80=99t think of another reason why the answer isn=E2=80=99t = already YES for all calls. If its no, its likely a permanent = configuration problem not a dynamic decision. In other words, B always = expects A to call it on behalf of some one. Likewise, C is always = expecting B. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Mar 26, 2015, at 1:31 PM, Justin Richer wrote: >>=20 >> As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap = draft. >>=20 >>=20 >> [ Client ] -> [ A ] -> [ B ] -> [ C ] >>=20 >> An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. >>=20 >>=20 >> In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of =E2=80=9C= I got a token, I get another token based on this to call someone = else=E2=80=9D. It=E2=80=99s also analogous to the refresh token flow, = but with access tokens going in and out. I=E2=80=99ve deployed this = setup several times in different service deployments. Even though there = is a performance hit in the additional round trips (as Phil brought up = in another thread), in these cases the desire to have the tokens hold = least privilege access rights (smallest set of scopes per service) = outweighed any performance hit (which was shown to be rather small in = practice). >>=20 >> What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for = what it is: a way for a token issuer to communicate to a token service = specific actions. At a high level, the spec would be something like: >>=20 >>=20 >>=20 >> 1. How to swap a token at an AS >> 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in >> 2. Get back a new token in a token response >> 2. Communicating act as / on behalf of semantics via a JWT assertion >> 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as = semantics >> 2. What to do (as an AS/RS) with a JWT with act-as semantics >> 3. How to create a JWT with on-behalf-of semeantics >> 4. What to do with a JWT with on-behalf-of-semantics >> 5. How to possibly represent these semantics with something other = than a JWT >>=20 >>=20 >>=20 >> Section 2 uses the syntax from section 1. Other applications, like = the one I laid out above, can use the syntax from section 1 as well. = This works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens. >>=20 >>=20 >> =E2=80=94 Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_2E2FD031-6213-4A06-9039-FBD98CEA9781 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVFGjlAAoJEDPAngkbd+w9OQkH/3mPdjTorgsT9DOZuWWpHy2P YxIJ1wYcYSp41q9pXtQ+ODwhSqV4kmYKYQywB1/ta42hJPAfnf2Gt9zRMClQ7J1W awYiuSOgNnus9OiwOg2v13nUYiqT1qVPzhVE6X0BqfEjTFF7hXP2KMI48nwRlejg LUCJkUpo4O7my9ODRCklnsupYwQ74wh4twEcId2jpfYYzKNRfRNnWeYjdt0JUp1L IaTeINvbirivSCTh6W/eEyn/wLGq6HO9t3oN/5UYgrhQDc2DIicsZoeI8uVkssIo TC+cZZAvyaSougf+uSufZXiXid1hvoSbQKYdAUbF8vJsbbGbW8IheQgVFA8nOK4= =sUyR -----END PGP SIGNATURE----- --Apple-Mail=_2E2FD031-6213-4A06-9039-FBD98CEA9781-- From nobody Thu Mar 26 13:17:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A871B2E39 for ; Thu, 26 Mar 2015 13:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZDHbbv3SF0jW for ; Thu, 26 Mar 2015 13:17:48 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AE51A8AC7 for ; Thu, 26 Mar 2015 13:17:47 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-48-5514696ae67b 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 37.7C.03493.A6964155; Thu, 26 Mar 2015 16:17:46 -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 t2QKHjBK021108; Thu, 26 Mar 2015 16:17:45 -0400 Received: from dhcp-b47c.meeting.ietf.org (dhcp-b47c.meeting.ietf.org [31.133.180.124]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2QKHhnx030551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Mar 2015 16:17:44 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_83BCC4CF-D596-475A-AC4A-1E2010950D33"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <583669811.2960904.1427400806728.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 26 Mar 2015 15:17:43 -0500 Message-Id: <975527F1-86D4-4D0E-9192-B60809A87040@mit.edu> References: <9c1sdvnf558khwgomc9by3ys.1427398956170@email.android.com> <583669811.2960904.1427400806728.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEKsWRmVeSWpSXmKPExsUixG6nrpuVKRJqcPGIjMXJt6/YLL51XWd2 YPJYsuQnk8esWYeZApiiuGxSUnMyy1KL9O0SuDIOXzvNVrCtn7Fi19xG1gbGtZVdjJwcEgIm EnP/nWOCsMUkLtxbz9bFyMUhJLCYSWLimzVgCSGBjYwSLfuUIRJXmCTuH/jAApIQFtCXWL69 jxXE5hUwkJh76gtYA7PAFEaJvZsMIaZKSTS9PsYIYrMJqEpMX9MCVsMp4CPRvPYzG4jNAhS/ cnwWUA0HUK+6RPtJFxCTV8BK4t2sFIi1bYwSP2feACsRASpp/u4NYkoIyEv0bEqfwCg4C8kN s5DcAGEnSaxYdYwRwtaWWLbwNTOErSmxv3s5C6a4hkTnt4msELa8xPa3c6DilhKLZ96AqreV uNW3AGqXncSjaYtYFzByr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAiOPheV HYzNh5QOMQpwMCrx8P7oFw4VYk0sK67MPcQoycGkJMrbniESKsSXlJ9SmZFYnBFfVJqTWnyI UQVo16MNqy8wSrHk5eelKonwOscC1fGmJFZWpRblw5RJc7AoifNu+sEXIiSQnliSmp2aWpBa BJOV4eBQkuDNBVkgWJSanlqRlplTgpBm4uA8xCjBwQM0XB+khre4IDG3ODMdIn+KUVFKnJcX JCEAksgozYPrhSXNV4ziQG8J895OB6riASZcuO5XQIOZgAafy+cDGVySiJCSamC0iJmhNeXb LyG+3+/ro7a4975wMdir4cHPeNHpsKVI8nnHjk2bPi2R1mD7cGDnopXpeU/+lHeEVTC8CxN6 7Cn8tV/yQnzEl7IVv595s7o94Pq8uYyt6rCFSJ2np/7W9s99Nm1RbVX/qi8+US88a7Ht9sx+ melZ65ecizBc6xBs++jEp19TjuoqsRRnJBpqMRcVJwIA2Hw7CnUDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:17:51 -0000 --Apple-Mail=_83BCC4CF-D596-475A-AC4A-1E2010950D33 Content-Type: multipart/alternative; boundary="Apple-Mail=_952E7F6C-088E-4093-8ABA-27A185A8AA72" --Apple-Mail=_952E7F6C-088E-4093-8ABA-27A185A8AA72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Not really, because it=E2=80=99s not refreshing access. It=E2=80=99s = getting access in the context of a separate access token, which wasn=E2=80= =99t issued to it. The mechanism is similar to a refresh token but = that=E2=80=99s it. =E2=80=94 Justin > On Mar 26, 2015, at 3:13 PM, Bill Mills = wrote: >=20 > By definition an access token is becoming a form of refresh token. = The "because my implementation didn't do it that way" isn't convincing = me. >=20 >=20 >=20 > On Thursday, March 26, 2015 12:44 PM, Justin Richer = wrote: >=20 >=20 > Because many implementations (including mine which does support my old = token chaining draft) treat access tokens and refresh tokens separately = in terms of data store and structure. Additionally, the refresh token is = tied to the client and presented by the client. But in this case it's = someone downstream, an RS, presenting the token. So unlike a refresh = token being presented by the one it was issued to, this token is being = presented by someone it was presented to. >=20 > The feeling is close, but not quite the same in either development or = assumptions. >=20 > -- Justin >=20 > / Sent from my phone / >=20 >=20 > -------- Original message -------- > From: Bill Mills > Date: 03/26/2015 2:24 PM (GMT-06:00) > To: Justin Richer , "" = > Subject: Re: [OAUTH-WG] Token Chaining Use Case >=20 > So why can't the access tokne simply be re-used as a refresh token? = Why would it need a new grant type at all? >=20 >=20 >=20 >=20 > On Thursday, March 26, 2015 11:31 AM, Justin Richer = wrote: >=20 >=20 > As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap = draft. >=20 >=20 > [ Client ] -> [ A ] -> [ B ] -> [ C ] >=20 > An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. >=20 >=20 > In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of =E2=80=9C= I got a token, I get another token based on this to call someone = else=E2=80=9D. It=E2=80=99s also analogous to the refresh token flow, = but with access tokens going in and out. I=E2=80=99ve deployed this = setup several times in different service deployments. Even though there = is a performance hit in the additional round trips (as Phil brought up = in another thread), in these cases the desire to have the tokens hold = least privilege access rights (smallest set of scopes per service) = outweighed any performance hit (which was shown to be rather small in = practice). >=20 > What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for = what it is: a way for a token issuer to communicate to a token service = specific actions. At a high level, the spec would be something like: >=20 >=20 >=20 > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as = semantics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other = than a JWT >=20 >=20 >=20 > Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This = works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens. >=20 >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 --Apple-Mail=_952E7F6C-088E-4093-8ABA-27A185A8AA72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Not really, because it=E2=80=99s not refreshing access. = It=E2=80=99s getting access in the context of a separate access token, = which wasn=E2=80=99t issued to it. The mechanism is similar to a refresh = token but that=E2=80=99s it.

 =E2=80=94 Justin

On = Mar 26, 2015, at 3:13 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

By = definition an access token is becoming a form of refresh token.   =  The "because my implementation didn't do it that way" isn't = convincing me.



On = Thursday, March 26, 2015 12:44 PM, Justin Richer <jricher@mit.edu> = wrote:


=
=20
Because many = implementations (including mine which does support my old token chaining = draft) treat access tokens and refresh tokens separately in terms of = data store and structure. Additionally, the refresh token is tied to the = client and presented by the client. But in this case it's someone = downstream, an RS, presenting the token. So unlike a refresh token being = presented by the one it was issued to, this token is being presented by = someone it was presented to. 

The feeling is close, but not quite = the same in either development or assumptions.

-- Justin

/= Sent from my phone /


-------- = Original message --------
From: Bill Mills = <wmills_92105@yahoo.com>
Date: 03/26/2015 2:24 PM (GMT-06:00)
To: Justin Richer <jricher@MIT.EDU>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: = Re: [OAUTH-WG] Token Chaining Use Case

So why can't the access tokne simply be re-used as a refresh = token?  Why would it need a new grant type at all?

=


On Thursday, = March 26, 2015 11:31 AM, Justin Richer <jricher@MIT.EDU> = wrote:


As requested after last night=E2=80= =99s informal meeting, here is the token chaining use case that I want = to see represented in the token swap draft.


[ = Client ]  ->  [ A ] -> [ B ] -> [ C ]

An OAuth client = gets an access token AT1, just like it always would, with scopes [A, B, = C] in order to call service A, which requires all three scopes. Service = A (an RS) accepts this token since it has its scope, and then needs to = call service B in turn, which requires scopes [B, C]. It could just = re-send the token it got in, AT1, but that would give the downstream RS = the ability to call services with scope [ A ] and it should not be = allowed to do that. To limit exposure, service A calls a token swap at = the AS to create AT2 with scopes [ B, C ], effectively acting as an = OAuth client requesting a downscoped token based on AT1. Service A then = acts as an OAuth client to call service B, now acting as an RS to = service A=E2=80=99s client, and can fulfill the request. And it=E2=80=99s = turtles all the way down: Service B can also call service C, and now B = acts as a client, requesting AT3 with scope [ C ] based on AT2, and = sending AT3 to service C. This prevents C from being able to call B or = A, both of which would have been available if AT1 had been passed = around. Note that service A or the Client can also request a downscoped = token with [ C ] to call service C directly as well, and C doesn=E2=80=99t= have to care how it got there.


In other words, = it lets the client software be very, very dumb. It doesn=E2=80=99t have = to do any special processing, doesn=E2=80=99t have to know what=E2=80=99s = in the token, it just follows the recipe of =E2=80=9CI got a token, I = get another token based on this to call someone else=E2=80=9D. It=E2=80=99= s also analogous to the refresh token flow, but with access tokens going = in and out. I=E2=80=99ve deployed this setup several times in different = service deployments. Even though there is a performance hit in the = additional round trips (as Phil brought up in another thread), in these = cases the desire to have the tokens hold least privilege access rights = (smallest set of scopes per service) outweighed any performance hit = (which was shown to be rather small in practice).

What I want is for the token = swap draft to define or use a mechanism that allows us to do this. I = think we can do that pretty easily by adjusting the token swap syntax = and language, and explicitly calling out the semantic processing portion = (the current core of the document) for what it is: a way for a token = issuer to communicate to a token service specific actions. At a high = level, the spec would be something like:



1. How to swap a token at an AS
  1. Send a request to the token endpoint with a new = grant type, and a token (of any type/format/flavor) on the way in
  2. Get back a new token in a token = response
2. Communicating act as / on = behalf of semantics via a JWT assertion
  1. How to create (as an AS/RS/client/other issuer) a = JWT with act-as semantics
  2. What to = do (as an AS/RS) with a JWT with act-as semantics
  3. How to create a JWT with on-behalf-of semeantics
  4. What to do with a JWT with = on-behalf-of-semantics
  5. How to = possibly represent these semantics with something other than a JWT



Section 2 uses the syntax from = section 1. Other applications, like the one I laid out above, can use = the syntax from section 1 as well. This works for structured, = unstructured, self-generated, cross-domain, within-domain, and other = tokens.


=E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




=

= --Apple-Mail=_952E7F6C-088E-4093-8ABA-27A185A8AA72-- --Apple-Mail=_83BCC4CF-D596-475A-AC4A-1E2010950D33 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVFGlnAAoJEDPAngkbd+w96QQH+gOVVsGCjQe+8DCzGbqScDEU 5ONhlrvWNniV6oCHgGOGnYnad7ujxd4BvonzVa4iDLSmlIoJ9ZC6MCCDNWCLXEZR dtmguZnGa878LTRgrxL3zerV9pX34tNZcR1FujW0iT9UlTJbyzUhXB15akQBdXw5 DKG243WCiW00VJ8321pqBHrgyVPmyfE3dkvF0TKkSsg+WMFDdq9a5rfv6YWDpiRI xCNRTV09/dHRTdaZBaqQCMOgk1lpw2PI8t51yGZ90LdAFbopLbRFxOMMnjNSPcxy p/Ftw2LwnzWWbdMeJNGq3fRMXfrlkmXsMXVmJnosRMp07Smn6RSMLCby8dJsO9w= =I2Za -----END PGP SIGNATURE----- --Apple-Mail=_83BCC4CF-D596-475A-AC4A-1E2010950D33-- From nobody Thu Mar 26 13:21:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936231B2E7C for ; Thu, 26 Mar 2015 13:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4PAi0CxrY3Kg for ; Thu, 26 Mar 2015 13:21:43 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F791B2E32 for ; Thu, 26 Mar 2015 13:21:42 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2QKLfDL002102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Mar 2015 20:21:42 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t2QKLf45018630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2015 20:21:41 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2QKLfDo018939; Thu, 26 Mar 2015 20:21:41 GMT Received: from [172.16.90.220] (/199.227.110.154) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Mar 2015 13:21:40 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-6D2C481D-65A8-49D4-AED7-CD1656E69477 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: <583669811.2960904.1427400806728.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 26 Mar 2015 15:21:42 -0500 Content-Transfer-Encoding: 7bit Message-Id: <4B76EE05-FF82-4B29-8A6C-22AFBBD7C93A@oracle.com> References: <9c1sdvnf558khwgomc9by3ys.1427398956170@email.android.com> <583669811.2960904.1427400806728.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:21:49 -0000 --Apple-Mail-6D2C481D-65A8-49D4-AED7-CD1656E69477 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. We all have to change production code when non final specs evolve.=20 I particularly don't see this as a valid argument at the start of a standard= s discussion.=20 Phil > On Mar 26, 2015, at 15:13, Bill Mills wrote: >=20 > By definition an access token is becoming a form of refresh token. The "= because my implementation didn't do it that way" isn't convincing me. >=20 >=20 >=20 > On Thursday, March 26, 2015 12:44 PM, Justin Richer wrot= e: >=20 >=20 > Because many implementations (including mine which does support my old tok= en chaining draft) treat access tokens and refresh tokens separately in term= s of data store and structure. Additionally, the refresh token is tied to th= e client and presented by the client. But in this case it's someone downstre= am, an RS, presenting the token. So unlike a refresh token being presented b= y the one it was issued to, this token is being presented by someone it was p= resented to.=20 >=20 > The feeling is close, but not quite the same in either development or assu= mptions. >=20 > -- Justin >=20 > / Sent from my phone / >=20 >=20 > -------- Original message -------- > From: Bill Mills =20 > Date: 03/26/2015 2:24 PM (GMT-06:00)=20 > To: Justin Richer , "" =20= > Subject: Re: [OAUTH-WG] Token Chaining Use Case=20 >=20 > So why can't the access tokne simply be re-used as a refresh token? Why w= ould it need a new grant type at all? >=20 >=20 >=20 >=20 > On Thursday, March 26, 2015 11:31 AM, Justin Richer wrot= e: >=20 >=20 > As requested after last night=E2=80=99s informal meeting, here is the toke= n chaining use case that I want to see represented in the token swap draft. >=20 >=20 > [ Client ] -> [ A ] -> [ B ] -> [ C ] >=20 > An OAuth client gets an access token AT1, just like it always would, with s= copes [A, B, C] in order to call service A, which requires all three scopes.= Service A (an RS) accepts this token since it has its scope, and then needs= to call service B in turn, which requires scopes [B, C]. It could just re-s= end the token it got in, AT1, but that would give the downstream RS the abil= ity to call services with scope [ A ] and it should not be allowed to do tha= t. To limit exposure, service A calls a token swap at the AS to create AT2 w= ith scopes [ B, C ], effectively acting as an OAuth client requesting a down= scoped token based on AT1. Service A then acts as an OAuth client to call se= rvice B, now acting as an RS to service A=E2=80=99s client, and can fulfill t= he request. And it=E2=80=99s turtles all the way down: Service B can also ca= ll service C, and now B acts as a client, requesting AT3 with scope [ C ] ba= sed on AT2, and sending AT3 to service C. This prevents C from being able to= call B or A, both of which would have been available if AT1 had been passed= around. Note that service A or the Client can also request a downscoped tok= en with [ C ] to call service C directly as well, and C doesn=E2=80=99t have= to care how it got there. >=20 >=20 > In other words, it lets the client software be very, very dumb. It doesn=E2= =80=99t have to do any special processing, doesn=E2=80=99t have to know what= =E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a toke= n, I get another token based on this to call someone else=E2=80=9D. It=E2=80= =99s also analogous to the refresh token flow, but with access tokens going i= n and out. I=E2=80=99ve deployed this setup several times in different servi= ce deployments. Even though there is a performance hit in the additional rou= nd trips (as Phil brought up in another thread), in these cases the desire t= o have the tokens hold least privilege access rights (smallest set of scopes= per service) outweighed any performance hit (which was shown to be rather s= mall in practice). >=20 > What I want is for the token swap draft to define or use a mechanism that a= llows us to do this. I think we can do that pretty easily by adjusting the t= oken swap syntax and language, and explicitly calling out the semantic proce= ssing portion (the current core of the document) for what it is: a way for a= token issuer to communicate to a token service specific actions. At a high l= evel, the spec would be something like: >=20 >=20 >=20 > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a tok= en (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as sem= antics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other than a= JWT >=20 >=20 >=20 > Section 2 uses the syntax from section 1. Other applications, like the one= I laid out above, can use the syntax from section 1 as well. This works for= structured, unstructured, self-generated, cross-domain, within-domain, and o= ther tokens. >=20 >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6D2C481D-65A8-49D4-AED7-CD1656E69477 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1. We all have to change production c= ode when non final specs evolve. 

I particular= ly don't see this as a valid argument at the start of a standards discussion= . 

Phil

On Mar 26, 2015, at 15:13, Bill Mil= ls <wmills_92105@yahoo.com&= gt; wrote:

By definition an access token is becomi= ng a form of refresh token.    The "because my implementation didn= 't do it that way" isn't convincing me.



On Thursday, March 26, 2015 12:44 PM, Justin Richer <jricher@mit.edu> wrote:

=
=20
Because many implementations (= including mine which does support my old token chaining draft) treat access t= okens and refresh tokens separately in terms of data store and structure. Ad= ditionally, the refresh token is tied to the client and presented by the cli= ent. But in this case it's someone downstream, an RS, presenting the token. S= o unlike a refresh token being presented by the one it was issued to, this t= oken is being presented by someone it was presented to. 

The feeling is close, but not quite the same in eit= her development or assumptions.

-- Justin

/ Sent from my phone /
<= div>


-------- Original mess= age --------
From: Bill Mills <wmills_92105@yahoo.com>
Date: 03= /26/2015 2:24 PM (GMT-06:00)
To: Justin Richer <jricher@MIT.EDU>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token= Chaining Use Case

So why can't the access tokne simply be re-use= d as a refresh token?  Why would it need a new grant type at all?




On Thursday, March 26, 2015 11:= 31 AM, Justin Richer <jricher@MIT.EDU<= /a>> wrote:


As requested after l= ast night=E2=80=99s informal meeting, here is the token chaining use case th= at I want to see represented in the token swap draft.


[ Client ]  ->  [ A ] -> [= B ] -> [ C ]

An OAuth client gets a= n access token AT1, just like it always would, with scopes [A, B, C] in orde= r to call service A, which requires all three scopes. Service A (an RS) acce= pts this token since it has its scope, and then needs to call service B in t= urn, which requires scopes [B, C]. It could just re-send the token it got in= , AT1, but that would give the downstream RS the ability to call services wi= th scope [ A ] and it should not be allowed to do that. To limit exposure, s= ervice A calls a token swap at the AS to create AT2 with scopes [ B, C ], ef= fectively acting as an OAuth client requesting a downscoped token based on A= T1. Service A then acts as an OAuth client to call service B, now acting as a= n RS to service A=E2=80=99s client, and can fulfill the request. And it=E2=80= =99s turtles all the way down: Service B can also call service C, and now B a= cts as a client, requesting AT3 with scope [ C ] based on AT2, and sending A= T3 to service C. This prevents C from being able to call B or A, both of whi= ch would have been available if AT1 had been passed around. Note that servic= e A or the Client can also request a downscoped token with [ C ] to call ser= vice C directly as well, and C doesn=E2=80=99t have to care how it got there= .


In other words, it= lets the client software be very, very dumb. It doesn=E2=80=99t have to do a= ny special processing, doesn=E2=80=99t have to know what=E2=80=99s in the to= ken, it just follows the recipe of =E2=80=9CI got a token, I get another tok= en based on this to call someone else=E2=80=9D. It=E2=80=99s also analogous t= o the refresh token flow, but with access tokens going in and out. I=E2=80=99= ve deployed this setup several times in different service deployments. Even t= hough there is a performance hit in the additional round trips (as Phil brou= ght up in another thread), in these cases the desire to have the tokens hold= least privilege access rights (smallest set of scopes per service) outweigh= ed any performance hit (which was shown to be rather small in practice).

What I want is for the token swap draft to d= efine or use a mechanism that allows us to do this. I think we can do that p= retty easily by adjusting the token swap syntax and language, and explicitly= calling out the semantic processing portion (the current core of the docume= nt) for what it is: a way for a token issuer to communicate to a token servi= ce specific actions. At a high level, the spec would be something like:



1. Ho= w to swap a token at an AS
  1. Send a request to the= token endpoint with a new grant type, and a token (of any type/format/flavo= r) on the way in
  2. Get back a new token in a token= response
2. Communicating act as / on behalf of semantics= via a JWT assertion
  1. How to create (as an AS/RS/= client/other issuer) a JWT with act-as semantics
  2.= What to do (as an AS/RS) with a JWT with act-as semantics
  3. How to create a JWT with on-behalf-of semeantics
  4. What to do with a JWT with on-behalf-of-semantics
  5. How to possibly represent these semantics with something other= than a JWT



Section 2 uses the syntax from section 1. Other applications, lik= e the one I laid out above, can use the syntax from section 1 as well. This w= orks for structured, unstructured, self-generated, cross-domain, within-doma= in, and other tokens.


=E2=80=94 Justin
______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




<= /blockquote>
___________________________= ____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth
= --Apple-Mail-6D2C481D-65A8-49D4-AED7-CD1656E69477-- From nobody Thu Mar 26 13:25:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D46F1B2B52 for ; Thu, 26 Mar 2015 13:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 s6PeaAD7MM2r for ; Thu, 26 Mar 2015 13:24:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C01C1A8A23 for ; Thu, 26 Mar 2015 13:24:58 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2QKOvrN005836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Mar 2015 20:24:57 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2QKOuRo013550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2015 20:24:56 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2QKOuKX028564; Thu, 26 Mar 2015 20:24:56 GMT Received: from [172.16.90.220] (/199.227.110.154) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Mar 2015 13:24:56 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: <91BF31B4-BDE5-4912-BFBE-C9FD8EB07A96@mit.edu> Date: Thu, 26 Mar 2015 15:24:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <50A1EA94-1B4F-4E3C-A495-E68C09F42547@oracle.com> References: <2574ED86-AC5F-4140-9A6D-0D4DEA0A2690@oracle.com> <91BF31B4-BDE5-4912-BFBE-C9FD8EB07A96@mit.edu> To: Justin Richer X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:25:01 -0000 See below Phil > On Mar 26, 2015, at 15:15, Justin Richer wrote: >=20 > Your service layout will determine whether or not each bit calls the same A= S that issued the original token, since you can easily do it across boundari= es if your AS takes in cross domain tokens. That=E2=80=99s another benefit o= f having it be a generic token swap, you can build it out using the same mec= hanism and get both behaviors. >=20 > The AS could reject the swap for any number of conditions: wrong client as= ked, token is expired, scopes don=E2=80=99t align, bad token, etc. >=20 > You can always optimize your system such that you just send a high-powered= token down the chain, in which case you=E2=80=99re not using token swapping= . This is not for those cases, obviously. This is for the cases when you *ar= e* doing token swapping and usually downscoping the privileges. There is no high power token in my new proposal. Each server must act on its= own authority with its own token. The original at is passed as evidence of s= coped authority to the internal services.=20 There is no super token.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 26, 2015, at 2:53 PM, Phil Hunt wrote: >>=20 >> What if A calls be with it=E2=80=99s own authorization token (server toke= n ST1) and passes AT1 in another header e.g. on-behalf-of. >>=20 >> You save a call and can still check the scope downstream. Further, servic= e B and C can each check whether ST1 and ST2 had the right to wield AT1 even= when AT1=E2=80=99s POP proof is a proof of the external client. >>=20 >> The only reason I can think to call the AS is if there is some dynamic co= ndition that might cause an AS to reject the swap. If AT1 is valid, I can=E2= =80=99t think of another reason why the answer isn=E2=80=99t already YES for= all calls. If its no, its likely a permanent configuration problem not a dy= namic decision. In other words, B always expects A to call it on behalf of s= ome one. Likewise, C is always expecting B. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Mar 26, 2015, at 1:31 PM, Justin Richer wrote: >>>=20 >>> As requested after last night=E2=80=99s informal meeting, here is the to= ken chaining use case that I want to see represented in the token swap draft= . >>>=20 >>>=20 >>> [ Client ] -> [ A ] -> [ B ] -> [ C ] >>>=20 >>> An OAuth client gets an access token AT1, just like it always would, wit= h scopes [A, B, C] in order to call service A, which requires all three scop= es. Service A (an RS) accepts this token since it has its scope, and then ne= eds to call service B in turn, which requires scopes [B, C]. It could just r= e-send the token it got in, AT1, but that would give the downstream RS the a= bility to call services with scope [ A ] and it should not be allowed to do t= hat. To limit exposure, service A calls a token swap at the AS to create AT2= with scopes [ B, C ], effectively acting as an OAuth client requesting a do= wnscoped token based on AT1. Service A then acts as an OAuth client to call s= ervice B, now acting as an RS to service A=E2=80=99s client, and can fulfill= the request. And it=E2=80=99s turtles all the way down: Service B can also c= all service C, and now B acts as a client, requesting AT3 with scope [ C ] b= ased on AT2, and sending AT3 to service C. This prevents C from being able t= o call B or A, both of which would have been available if AT1 had been passe= d around. Note that service A or the Client can also request a downscoped to= ken with [ C ] to call service C directly as well, and C doesn=E2=80=99t hav= e to care how it got there. >>>=20 >>>=20 >>> In other words, it lets the client software be very, very dumb. It doesn= =E2=80=99t have to do any special processing, doesn=E2=80=99t have to know w= hat=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a t= oken, I get another token based on this to call someone else=E2=80=9D. It=E2= =80=99s also analogous to the refresh token flow, but with access tokens goi= ng in and out. I=E2=80=99ve deployed this setup several times in different s= ervice deployments. Even though there is a performance hit in the additional= round trips (as Phil brought up in another thread), in these cases the desi= re to have the tokens hold least privilege access rights (smallest set of sc= opes per service) outweighed any performance hit (which was shown to be rath= er small in practice). >>>=20 >>> What I want is for the token swap draft to define or use a mechanism tha= t allows us to do this. I think we can do that pretty easily by adjusting th= e token swap syntax and language, and explicitly calling out the semantic pr= ocessing portion (the current core of the document) for what it is: a way fo= r a token issuer to communicate to a token service specific actions. At a hi= gh level, the spec would be something like: >>>=20 >>>=20 >>>=20 >>> 1. How to swap a token at an AS >>> 1. Send a request to the token endpoint with a new grant type, and a tok= en (of any type/format/flavor) on the way in >>> 2. Get back a new token in a token response >>> 2. Communicating act as / on behalf of semantics via a JWT assertion >>> 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as sem= antics >>> 2. What to do (as an AS/RS) with a JWT with act-as semantics >>> 3. How to create a JWT with on-behalf-of semeantics >>> 4. What to do with a JWT with on-behalf-of-semantics >>> 5. How to possibly represent these semantics with something other than a= JWT >>>=20 >>>=20 >>>=20 >>> Section 2 uses the syntax from section 1. Other applications, like the o= ne I laid out above, can use the syntax from section 1 as well. This works f= or structured, unstructured, self-generated, cross-domain, within-domain, an= d other tokens. >>>=20 >>>=20 >>> =E2=80=94 Justin >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Thu Mar 26 13:36:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ABA1B2EC0 for ; Thu, 26 Mar 2015 13:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 YjDqRF1y4jAQ for ; Thu, 26 Mar 2015 13:35:56 -0700 (PDT) Received: from nm34-vm3.bullet.mail.bf1.yahoo.com (nm34-vm3.bullet.mail.bf1.yahoo.com [72.30.239.75]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499551A90BD for ; Thu, 26 Mar 2015 13:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427402155; bh=CNEnoTjx0eHLUiCQbCc16IHccsfRnEBn74UQDnaq8UY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=AK28MTd0rMSZ1g5tLUGG8nDq9BSrV1ZuCBjhKKJHFRySWY9p2ia+csjYXo4S3SLVc/X/zP3L/m49orZjpZwZPtmP0MWSzDfnutX5Fy5xk1wpfe5kI2+X1DigMT3OA8yPlRkZvfpK/ZqClOb7UnbOD5SA3QOq2SvD2BxVF+Nb692JsKm07xbdv+ivlCAOreSFDyE42QLVMZL2ZXya5OLv60D4WkAFi13YqqqDHZzNn+jSa+bEKMBkY/UuOuu8yqtfZSHnDrjXuNAMcetO1jkujFb8kpwSwjhEDSer9RGzJacrNQt8OXDLAfRSVKo0vwFPYk9ZcyFaTU1pnCT1A7DVng== Received: from [66.196.81.170] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 20:35:55 -0000 Received: from [98.139.212.202] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 20:35:55 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 20:35:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 533738.61913.bm@omp1011.mail.bf1.yahoo.com X-YMail-OSG: EX_S2MEVM1lPeFYqS_nBlqyY5Kcz4N150L4dGeoiSePPnl1LjGCDi52u3I3Y.Uy lPzVdoJ9IGWBa.EWUO1IbZeOS0i8pAJPaM7y3GuwzpX.o8lGzlHvksEuOZ1xeXqYOPT5Kj8q5Adk cV9_XWIPmVYeTJ254Hq18jpk7Pv2qaxJ7nQ.1Hni5yCfArRnJWaspVt2N7jdpp4fFyB9WJ.4V1nC guWQj1B.4PtkKyf1bBcrE9chr5eKhjuO936pKniiISsF5T7IPYR1eqyqfnIw.hREg7WCV44Be4p8 _brxT84JQwrkC0TZzv_3LSSUU.EEeNh3XxoIuSVCKvLB30jeoGytkGAuz1UN2eQfG8x3qBV0h1v0 C0w4SVcQkUgGDPMkQ5yjzU5l9K7wfL6ZBJYh4slknYnFvvkQMK6c4Yv8Z5_7N7cC9Jh7tyc2QslG NoTC7TR6ScX5fCKqtr5Sfsu3Rfg.RQWbpI7kahlRtHW5EGb9vEWvVC3x0yXpZGFZhXrTyqEFXasA arQizRSG2qXzNAodS5H8DFYnxyKJxFzNsTvrQd1MQdZI0cdrQUbRtcl4oOR5pQ.nEL2GHheFfFGM tg_qN6bxxE9PeuTjcWdKOgCfg1oeKl9jm.sNbx8dK Received: by 66.196.81.119; Thu, 26 Mar 2015 20:35:55 +0000 Date: Thu, 26 Mar 2015 20:35:54 +0000 (UTC) From: Bill Mills To: Phil Hunt , Justin Richer Message-ID: <646810896.2964389.1427402154696.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <50A1EA94-1B4F-4E3C-A495-E68C09F42547@oracle.com> References: <50A1EA94-1B4F-4E3C-A495-E68C09F42547@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2964388_1040177069.1427402154691" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:35:59 -0000 ------=_Part_2964388_1040177069.1427402154691 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Requiring a round trip to the AS is going to have a huge headwind for imple= mentation in high performance environments. I think we need to pursue something like what Phil is talking about where t= he intermediary server has it's own credential or authority.=C2=A0=20 On Thursday, March 26, 2015 1:25 PM, Phil Hunt = wrote: =20 See below Phil > On Mar 26, 2015, at 15:15, Justin Richer wrote: >=20 > Your service layout will determine whether or not each bit calls the same= AS that issued the original token, since you can easily do it across bound= aries if your AS takes in cross domain tokens. That=E2=80=99s another benef= it of having it be a generic token swap, you can build it out using the sam= e mechanism and get both behaviors. >=20 > The AS could reject the swap for any number of conditions: wrong client a= sked, token is expired, scopes don=E2=80=99t align, bad token, etc. >=20 > You can always optimize your system such that you just send a high-powere= d token down the chain, in which case you=E2=80=99re not using token swappi= ng. This is not for those cases, obviously. This is for the cases when you = *are* doing token swapping and usually downscoping the privileges. There is no high power token in my new proposal. Each server must act on it= s own authority with its own token. The original at is passed as evidence o= f scoped authority to the internal services.=20 There is no super token.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 26, 2015, at 2:53 PM, Phil Hunt wrote: >>=20 >> What if A calls be with it=E2=80=99s own authorization token (server tok= en ST1) and passes AT1 in another header e.g. on-behalf-of. >>=20 >> You save a call and can still check the scope downstream. Further, servi= ce B and C can each check whether ST1 and ST2 had the right to wield AT1 ev= en when AT1=E2=80=99s POP proof is a proof of the external client. >>=20 >> The only reason I can think to call the AS is if there is some dynamic c= ondition that might cause an AS to reject the swap.=C2=A0 If AT1 is valid, = I can=E2=80=99t think of another reason why the answer isn=E2=80=99t alread= y YES for all calls. If its no, its likely a permanent configuration proble= m not a dynamic decision.=C2=A0 In other words, B always expects A to call = it on behalf of some one.=C2=A0 Likewise, C is always expecting B. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Mar 26, 2015, at 1:31 PM, Justin Richer wrote: >>>=20 >>> As requested after last night=E2=80=99s informal meeting, here is the t= oken chaining use case that I want to see represented in the token swap dra= ft. >>>=20 >>>=20 >>> [ Client ]=C2=A0 ->=C2=A0 [ A ] -> [ B ] -> [ C ] >>>=20 >>> An OAuth client gets an access token AT1, just like it always would, wi= th scopes [A, B, C] in order to call service A, which requires all three sc= opes. Service A (an RS) accepts this token since it has its scope, and then= needs to call service B in turn, which requires scopes [B, C]. It could ju= st re-send the token it got in, AT1, but that would give the downstream RS = the ability to call services with scope [ A ] and it should not be allowed = to do that. To limit exposure, service A calls a token swap at the AS to cr= eate AT2 with scopes [ B, C ], effectively acting as an OAuth client reques= ting a downscoped token based on AT1. Service A then acts as an OAuth clien= t to call service B, now acting as an RS to service A=E2=80=99s client, and= can fulfill the request. And it=E2=80=99s turtles all the way down: Servic= e B can also call service C, and now B acts as a client, requesting AT3 wit= h scope [ C ] based on AT2, and sending AT3 to service C. This prevents C f= rom being able to call B or A, both of which would have been available if A= T1 had been passed around. Note that service A or the Client can also reque= st a downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. >>>=20 >>>=20 >>> In other words, it lets the client software be very, very dumb. It does= n=E2=80=99t have to do any special processing, doesn=E2=80=99t have to know= what=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got = a token, I get another token based on this to call someone else=E2=80=9D. I= t=E2=80=99s also analogous to the refresh token flow, but with access token= s going in and out. I=E2=80=99ve deployed this setup several times in diffe= rent service deployments. Even though there is a performance hit in the add= itional round trips (as Phil brought up in another thread), in these cases = the desire to have the tokens hold least privilege access rights (smallest = set of scopes per service) outweighed any performance hit (which was shown = to be rather small in practice). >>>=20 >>> What I want is for the token swap draft to define or use a mechanism th= at allows us to do this. I think we can do that pretty easily by adjusting = the token swap syntax and language, and explicitly calling out the semantic= processing portion (the current core of the document) for what it is: a wa= y for a token issuer to communicate to a token service specific actions. At= a high level, the spec would be something like: >>>=20 >>>=20 >>>=20 >>> 1. How to swap a token at an AS >>> 1. Send a request to the token endpoint with a new grant type, and a to= ken (of any type/format/flavor) on the way in >>> 2. Get back a new token in a token response >>> 2. Communicating act as / on behalf of semantics via a JWT assertion >>> 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as se= mantics >>> 2. What to do (as an AS/RS) with a JWT with act-as semantics >>> 3. How to create a JWT with on-behalf-of semeantics >>> 4. What to do with a JWT with on-behalf-of-semantics >>> 5. How to possibly represent these semantics with something other than = a JWT >>>=20 >>>=20 >>>=20 >>> Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This works= for structured, unstructured, self-generated, cross-domain, within-domain,= and other tokens. >>>=20 >>>=20 >>> =E2=80=94 Justin >>> _______________________________________________ >>> 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 ------=_Part_2964388_1040177069.1427402154691 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Requiring a round trip to the A= S is going to have a huge headwind for implementation in high performance e= nvironments.

I think we nee= d to pursue something like what Phil is talking about where the intermediar= y server has it's own credential or authority. 



On Thursday, March 26, 2015 1:25 PM, Phil Hunt <phil.hunt@= oracle.com> wrote:


See below

Phil

> On Mar 26, 2015, at 15:15, Justin Richer <jricher@mit.edu> wrote:
>
> Your service layout will determine whether or not each bit calls t= he same AS that issued the original token, since you can easily do it acros= s boundaries if your AS takes in cross domain tokens. That=E2=80=99s anothe= r benefit of having it be a generic token swap, you can build it out using = the same mechanism and get both behaviors.
>
> The AS could reject the swap for any number of conditions: w= rong client asked, token is expired, scopes don=E2=80=99t align, bad token,= etc.
>
> You can always optimiz= e your system such that you just send a high-powered token down the chain, = in which case you=E2=80=99re not using token swapping. This is not for thos= e cases, obviously. This is for the cases when you *are* doing token swappi= ng and usually downscoping the privileges.

There is no high power token in my new proposal. Each server must act = on its own authority with its own token. The original at is passed as evide= nce of scoped authority to the internal services.

There is no super token.


>
>= ; =E2=80=94 Justin
>
>> On Ma= r 26, 2015, at 2:53 PM, Phil Hunt <phil.hunt@oracle.= com> wrote:
>>
>> W= hat if A calls be with it=E2=80=99s own authorization token (server token S= T1) and passes AT1 in another header e.g. on-behalf-of.
&= gt;>
>> You save a call and can still check the= scope downstream. Further, service B and C can each check whether ST1 and = ST2 had the right to wield AT1 even when AT1=E2=80=99s POP proof is a proof= of the external client.
>>
>= > The only reason I can think to call the AS is if there is some dynamic= condition that might cause an AS to reject the swap.  If AT1 is valid= , I can=E2=80=99t think of another reason why the answer isn=E2=80=99t alre= ady YES for all calls. If its no, its likely a permanent configuration prob= lem not a dynamic decision.  In other words, B always expects A to cal= l it on behalf of some one.  Likewise, C is always expecting B.
>>
>> Phil
>= ;>
>> @independentid
>>= www.independentid.com
>> phil.= hunt@oracle.com
>>
>>&= gt; On Mar 26, 2015, at 1:31 PM, Justin Richer <jricher@MIT.ED= U> wrote:
>>>
>>= > As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap dr= aft.
>>>
>>>
>>> [ Client ]  ->  [ A ] -> [ B ] -&= gt; [ C ]
>>>
>>> An= OAuth client gets an access token AT1, just like it always would, with sco= pes [A, B, C] in order to call service A, which requires all three scopes. = Service A (an RS) accepts this token since it has its scope, and then needs= to call service B in turn, which requires scopes [B, C]. It could just re-= send the token it got in, AT1, but that would give the downstream RS the ab= ility to call services with scope [ A ] and it should not be allowed to do = that. To limit exposure, service A calls a token swap at the AS to create A= T2 with scopes [ B, C ], effectively acting as an OAuth client requesting a= downscoped token based on AT1. Service A then acts as an OAuth client to c= all service B, now acting as an RS to service A=E2=80=99s client, and can f= ulfill the request. And it=E2=80=99s turtles all the way down: Service B ca= n also call service C, and now B acts as a client, requesting AT3 with scop= e [ C ] based on AT2, and sending AT3 to service C. This prevents C from be= ing able to call B or A, both of which would have been available if AT1 had= been passed around. Note that service A or the Client can also request a d= ownscoped token with [ C ] to call service C directly as well, and C doesn= =E2=80=99t have to care how it got there.
>>> >>>
>>> In other word= s, it lets the client software be very, very dumb. It doesn=E2=80=99t have = to do any special processing, doesn=E2=80=99t have to know what=E2=80=99s i= n the token, it just follows the recipe of =E2=80=9CI got a token, I get an= other token based on this to call someone else=E2=80=9D. It=E2=80=99s also = analogous to the refresh token flow, but with access tokens going in and ou= t. I=E2=80=99ve deployed this setup several times in different service depl= oyments. Even though there is a performance hit in the additional round tri= ps (as Phil brought up in another thread), in these cases the desire to hav= e the tokens hold least privilege access rights (smallest set of scopes per= service) outweighed any performance hit (which was shown to be rather smal= l in practice).
>>>
>>&= gt; What I want is for the token swap draft to define or use a mechanism th= at allows us to do this. I think we can do that pretty easily by adjusting = the token swap syntax and language, and explicitly calling out the semantic= processing portion (the current core of the document) for what it is: a wa= y for a token issuer to communicate to a token service specific actions. At= a high level, the spec would be something like:
>>= >
>>>
>>>
>>> 1. How to swap a token at an AS
>>> 1. Send a request to the token endpoint with a new grant type= , and a token (of any type/format/flavor) on the way in
&= gt;>> 2. Get back a new token in a token response
&= gt;>> 2. Communicating act as / on behalf of semantics via a JWT asse= rtion
>>> 1. How to create (as an AS/RS/client/o= ther issuer) a JWT with act-as semantics
>>> 2. = What to do (as an AS/RS) with a JWT with act-as semantics
>>> 3. How to create a JWT with on-behalf-of semeantics
>>> 4. What to do with a JWT with on-behalf-of-semantics=
>>> 5. How to possibly represent these semantic= s with something other than a JWT
>>>
>>>
>>>
&= gt;>> Section 2 uses the syntax from section 1. Other applications, l= ike the one I laid out above, can use the syntax from section 1 as well. Th= is works for structured, unstructured, self-generated, cross-domain, within= -domain, and other tokens.
>>>
>>>
>>> =E2=80=94 Justin
>>> _______________________________________________
>>> OAuth mailing list
>>> <= a shape=3D"rect" ymailto=3D"mailto:OAuth@ietf.org" href=3D"mailto:OAuth@iet= f.org">OAuth@ietf.org
>>> http= s://www.ietf.org/mailman/listinfo/oauth
>

_____________________________________________= __
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/list= info/oauth


------=_Part_2964388_1040177069.1427402154691-- From nobody Thu Mar 26 13:47:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231341B2EF9 for ; Thu, 26 Mar 2015 13:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.634 X-Spam-Level: X-Spam-Status: No, score=0.634 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, IP_NOT_FRIENDLY=0.334, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 gipvpaBFJYMy for ; Thu, 26 Mar 2015 13:46:57 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 7ECCA1B2A0D for ; Thu, 26 Mar 2015 13:46:57 -0700 (PDT) Received: (qmail 27184 invoked by uid 0); 26 Mar 2015 20:46:55 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 26 Mar 2015 20:46:55 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw4 with id 8Smn1q0182is6CS01Smq49; Thu, 26 Mar 2015 20:46:54 -0600 X-Authority-Analysis: v=2.1 cv=IIiRVGfG c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=UMhCEPvdHqkA:10 a=emO1SXQWCLwA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=yPCof4ZbAAAA:8 a=48vgC7mUAAAA:8 a=CjxXgO3LAAAA:8 a=B1YYlZYh479o0BpsGRMA:9 a=UR4bKcEDoFfWcY6O:21 a=rdXnX6URHWcuMcOF:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Vc0w8uqis1bIRFUZ1dsA:9 a=yikH7d3tbMqEf-ND:21 a=yBbONKZ7VuVTEze9:21 a=dE5TfA5dQL2OilNN:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=yxM3k3sXYBbEAz25EeSAzqvri28B6QgjlQckRWFoj6w=; b=CNhq4y2b/fuu5lm6l9652JHSGJUDYzz7W2SV88rvCv5WiQlfIEmSLaUvXpxVjaRNlnbUz3zNBR/i1BEO/ldrsUo4/CPHhkY2kWnm4CP1LqbLhr+N9tPs7tXJR54lXV1H; Received: from [104.176.153.192] (port=52225 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YbEfx-0005Uo-2C; Thu, 26 Mar 2015 14:46:49 -0600 From: "Donald F. Coffin" To: "'Phil Hunt'" , "'Bill Mills'" References: <9c1sdvnf558khwgomc9by3ys.1427398956170@email.android.com> <583669811.2960904.1427400806728.JavaMail.yahoo@mail.yahoo.com> <4B76EE05-FF82-4B29-8A6C-22AFBBD7C93A@oracle.com> In-Reply-To: <4B76EE05-FF82-4B29-8A6C-22AFBBD7C93A@oracle.com> Date: Thu, 26 Mar 2015 16:46:44 -0400 Organization: REMI Networks Message-ID: <002a01d06805$fa89e290$ef9da7b0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01D067E4.7379C930" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE2MoPsLp6UEreOrvNem34u7pwhKgJQoQoNAnrmMq+ePUlxcA== Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 104.176.153.192 authed with donald.coffin@reminetworks.com} Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:47:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002B_01D067E4.7379C930 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -1 =20 Although Justin=E2=80=99s point might be a bit pre-mature as far as a = standards discussion, the more critical reason IMHO is calling the = AS=E2=80=99s /Token endpoint with a grant_type of = =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rather than = an issued refresh_token (RT) will definitely create a backwards = compatibility issue for many implementations. =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: Subject: Re: [OAUTH-WG] Token Chaining Use Case =20 +1. We all have to change production code when non final specs evolve.=20 =20 I particularly don't see this as a valid argument at the start of a = standards discussion.=20 Phil On Mar 26, 2015, at 15:13, Bill Mills > wrote: By definition an access token is becoming a form of refresh token. = The "because my implementation didn't do it that way" isn't convincing = me. =20 =20 On Thursday, March 26, 2015 12:44 PM, Justin Richer > wrote: =20 Because many implementations (including mine which does support my old = token chaining draft) treat access tokens and refresh tokens separately = in terms of data store and structure. Additionally, the refresh token is = tied to the client and presented by the client. But in this case it's = someone downstream, an RS, presenting the token. So unlike a refresh = token being presented by the one it was issued to, this token is being = presented by someone it was presented to.=20 =20 The feeling is close, but not quite the same in either development or = assumptions. =20 -- Justin =20 / Sent from my phone / -------- Original message -------- From: Bill Mills = >=20 Date: 03/26/2015 2:24 PM (GMT-06:00)=20 To: Justin Richer >, = " >" >=20 Subject: Re: [OAUTH-WG] Token Chaining Use Case=20 So why can't the access tokne simply be re-used as a refresh token? Why = would it need a new grant type at all? =20 =20 =20 On Thursday, March 26, 2015 11:31 AM, Justin Richer > wrote: =20 As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap = draft. [ Client ] -> [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of = =E2=80=9CI got a token, I get another token based on this to call = someone else=E2=80=9D. It=E2=80=99s also analogous to the refresh token = flow, but with access tokens going in and out. I=E2=80=99ve deployed = this setup several times in different service deployments. Even though = there is a performance hit in the additional round trips (as Phil = brought up in another thread), in these cases the desire to have the = tokens hold least privilege access rights (smallest set of scopes per = service) outweighed any performance hit (which was shown to be rather = small in practice). What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for = what it is: a way for a token issuer to communicate to a token service = specific actions. At a high level, the spec would be something like: 1. How to swap a token at an AS 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as = semantics 2. What to do (as an AS/RS) with a JWT with act-as semantics 3. How to create a JWT with on-behalf-of semeantics 4. What to do with a JWT with on-behalf-of-semantics 5. How to possibly represent these semantics with something other than = a JWT Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This = works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens. =E2=80=94 Justin _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_002B_01D067E4.7379C930 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

-1

 

Although = =C2=A0Justin=E2=80=99s point might be a bit pre-mature as far as a = standards discussion, the more critical reason IMHO is calling the = AS=E2=80=99s /Token endpoint with a grant_type of = =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rather than = an issued refresh_token (RT) will definitely create a backwards = compatibility issue for many implementations.

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO<= /p>

 

REMI = Networks

2335 Dunwoody Crossing Suite = E

Dunwoody, GA = 30338-8221

 

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

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

 

From:<= /b> = Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, March = 26, 2015 4:22 PM
To: Bill Mills
Cc: = <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Chaining = Use Case

 

+1. We = all have to change production code when non final specs = evolve. 

 

I = particularly don't see this as a valid argument at the start of a = standards discussion. 


Phil


On Mar 26, 2015, at 15:13, Bill Mills = <wmills_92105@yahoo.com> = wrote:

= By definition an access token is becoming a form of refresh token. =    The "because my implementation didn't do it that = way" isn't convincing me.

=  

=  

On = Thursday, March 26, 2015 12:44 PM, Justin Richer <jricher@mit.edu> = wrote:

 

Because many = implementations (including mine which does support my old token chaining = draft) treat access tokens and refresh tokens separately in terms of = data store and structure. Additionally, the refresh token is tied to the = client and presented by the client. But in this case it's someone = downstream, an RS, presenting the token. So unlike a refresh token being = presented by the one it was issued to, this token is being presented by = someone it was presented to. 

 

The feeling is = close, but not quite the same in either development or = assumptions.

 

= -- Justin

=  

= / Sent from my phone /



--------= Original message --------
From: Bill Mills <wmills_92105@yahoo.com> =
Date: 03/26/2015 2:24 PM (GMT-06:00)
To: Justin Richer <jricher@MIT.EDU>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: = [OAUTH-WG] Token Chaining Use Case

= So why can't the access tokne simply be re-used as a refresh token? =  Why would it need a new grant type at = all?

=  

=  

=  

On = Thursday, March 26, 2015 11:31 AM, Justin Richer <jricher@MIT.EDU> = wrote:

 

As requested = after last night=E2=80=99s informal meeting, here is the token chaining = use case that I want to see represented in the token swap = draft.


[ Client ]  ->  [ A ] -> [ B ] -> [ = C ]

An OAuth client gets an access token AT1, just like it always = would, with scopes [A, B, C] in order to call service A, which requires = all three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there.


In other = words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of = =E2=80=9CI got a token, I get another token based on this to call = someone else=E2=80=9D. It=E2=80=99s also analogous to the refresh token = flow, but with access tokens going in and out. I=E2=80=99ve deployed = this setup several times in different service deployments. Even though = there is a performance hit in the additional round trips (as Phil = brought up in another thread), in these cases the desire to have the = tokens hold least privilege access rights (smallest set of scopes per = service) outweighed any performance hit (which was shown to be rather = small in practice).

What I want is for the token swap draft to = define or use a mechanism that allows us to do this. I think we can do = that pretty easily by adjusting the token swap syntax and language, and = explicitly calling out the semantic processing portion (the current core = of the document) for what it is: a way for a token issuer to communicate = to a token service specific actions. At a high level, the spec would be = something like:



1. How to swap a token at an AS
  = 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in
  2. Get back a = new token in a token response
2. Communicating act as / on behalf of = semantics via a JWT assertion
  1. How to create (as an = AS/RS/client/other issuer) a JWT with act-as semantics
  2. What = to do (as an AS/RS) with a JWT with act-as semantics
  3. How to = create a JWT with on-behalf-of semeantics
  4. What to do with a = JWT with on-behalf-of-semantics
  5. How to possibly represent = these semantics with something other than a JWT



Section 2 = uses the syntax from section 1. Other applications, like the one I laid = out above, can use the syntax from section 1 as well. This works for = structured, unstructured, self-generated, cross-domain, within-domain, = and other tokens.


=E2=80=94 = Justin
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

 

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

------=_NextPart_000_002B_01D067E4.7379C930-- From nobody Thu Mar 26 14:13:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1731A89FA for ; Thu, 26 Mar 2015 14:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 iy1QUiCeaBKq for ; Thu, 26 Mar 2015 14:13:29 -0700 (PDT) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404E01B2F14 for ; Thu, 26 Mar 2015 14:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427404408; bh=zI8xaHvcH2btLA7qWJygbdFEb7z1iVPGJAu/UKGvmdg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=FaDcdCbOC5obVBSLSUOdmcSFwdcHmKVptRE72M4TITTx1NgQ30ot4B1b7AUFyVD09xrIjGaI24al76xCMnqHD9N2VPAhM8hG+QTRAjDnIXxOeCWqUPgl5eKr7nR553HD9hci9lDMPpDakNmgJgWsW1TG9+PgGLIp9QedLf+dYGUMg9M1SJpqZGaopSIS8mwyO/4z1czVxVr0t1/GG2D+oJ5vcVTyeDh0sHmqd5jGPh6k9lXDD2AhG26RWoSIkIReQb2YmoIHlkz6N49N6jgQ6uphWzJj78Bs3KVclYeuP1eRN4Yha9K5jdbNkaT7tNRBUoyc7hX/2vgIPLG+gLsmEA== Received: from [66.196.81.171] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 21:13:28 -0000 Received: from [98.139.212.250] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 21:13:28 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 21:13:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 189542.76225.bm@omp1059.mail.bf1.yahoo.com X-YMail-OSG: HzxF4EwVM1le5RdwSTbi7PCyfNlyQnn_bcw6fW6QeTb1ssuyJfMysCrW6WYWLPX wuwxObLIFIYjj0a3rK0QUtwZUgc_qDQsM4ZgByznQo9kHlA7VNh9H9EHHghCUmGI6eZiSD3TsA_0 U556WtbkdxFRp01nO6eQ._ungdQVq27Py7Uyyl4TOdEvjqNLDmVv4BvhNtC6hiHWnnVhxsQJxVeV BxilFPW6_.ZR6yK5tUu1qko14GJAWGgJ86jooxr.HaB8JxSUPL3leZsrA2uLpx8ciBJ.EugU7BEI B0aNs.a.Z_KV5wSAeX9CUowW4kID5kJf5otWwzoAEQKXvzzp4E1CHdlL4EKJee5GJoBVurn5rDOQ ya.Md4rhLn6ggWBaI5TekmBXzv5G4deDyhTWygXX3_7ABFSVvSMDnt4ky003KWFnAXESvMIkNY8S uux3U7iUsiXJRRqhuIgdCMbXwkN550ID59p_IiEwuXQu2qPwu8YD7c2.v4gG0NO8Pmk8odmp5xNd ly1yxwVTBrdeVmn2NudzoyxBbX9cklXH1z7nEjBxv Received: by 66.196.80.120; Thu, 26 Mar 2015 21:13:27 +0000 Date: Thu, 26 Mar 2015 21:13:05 +0000 (UTC) From: Bill Mills To: "Donald F. Coffin" , 'Phil Hunt' Message-ID: <979394715.2988154.1427404385148.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <002a01d06805$fa89e290$ef9da7b0$@reminetworks.com> References: <002a01d06805$fa89e290$ef9da7b0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2988153_2098028161.1427404385133" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:13:32 -0000 ------=_Part_2988153_2098028161.1427404385133 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The RS calling back to the AS won't be confused, the token it gets would be= it's refresh token. =C2=A0I don't see any reason why the AS can't be smart= enough to know that a token that looks like an access token it issued is u= sable as a refresh token for limited purposes or downscoping. =C2=A0 On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin wrote: =20 #yiv0625374937 #yiv0625374937 -- _filtered #yiv0625374937 {font-family:Hel= vetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0625374937 {panose-1:2= 4 5 3 5 4 6 3 2 4;} _filtered #yiv0625374937 {font-family:Calibri;panose-1= :2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0625374937 {font-family:Cambria;panos= e-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0625374937 {panose-1:3 6 8 2 4 4 6 = 7 3 4;}#yiv0625374937 #yiv0625374937 p.yiv0625374937MsoNormal, #yiv06253749= 37 li.yiv0625374937MsoNormal, #yiv0625374937 div.yiv0625374937MsoNormal {ma= rgin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0625374937 a:link, #yi= v0625374937 span.yiv0625374937MsoHyperlink {color:blue;text-decoration:unde= rline;}#yiv0625374937 a:visited, #yiv0625374937 span.yiv0625374937MsoHyperl= inkFollowed {color:purple;text-decoration:underline;}#yiv0625374937 span.yi= v0625374937EmailStyle17 {color:windowtext;font-weight:normal;font-style:nor= mal;text-decoration:none none;}#yiv0625374937 .yiv0625374937MsoChpDefault {= font-size:10.0pt;} _filtered #yiv0625374937 {margin:1.0in 1.0in 1.0in 1.0in= ;}#yiv0625374937 div.yiv0625374937WordSection1 {}#yiv0625374937 -1 =C2=A0Al= though =C2=A0Justin=E2=80=99s point might be a bit pre-mature as far as a s= tandards discussion, the more critical reason IMHO is calling the AS=E2=80= =99s /Token endpoint with a grant_type of =E2=80=9Crefresh_token=E2=80=9D b= ut providing an issued AT rather than an issued refresh_token (RT) will def= initely create a backwards compatibility issue for many implementations. = =C2=A0Best regards,DonDonald F. CoffinFounder/CTO =C2=A0REMI Networks2335 D= unwoody Crossing Suite EDunwoody, GA 30338-8221 =C2=A0Phone:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 (949) 636-8571Email:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do= nald.coffin@reminetworks.com =C2=A0From: Phil Hunt [mailto:phil.hunt@oracle= .com]=20 Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: Subject: Re: [OAUTH-WG] Token Chaining Use Case =C2=A0+1. We all have to ch= ange production code when non final specs evolve.=C2=A0 =C2=A0I particularl= y don't see this as a valid argument at the start of a standards discussion= .=C2=A0 Phil On Mar 26, 2015, at 15:13, Bill Mills wrote: By definition an access token is becoming a form of refresh token. =C2=A0 = =C2=A0The "because my implementation didn't do it that way" isn't convincin= g me. =C2=A0 =C2=A0On Thursday, March 26, 2015 12:44 PM, Justin Richer wrote: =C2=A0Because many implementations (including mine whi= ch does support my old token chaining draft) treat access tokens and refres= h tokens separately in terms of data store and structure. Additionally, the= refresh token is tied to the client and presented by the client. But in th= is case it's someone downstream, an RS, presenting the token. So unlike a r= efresh token being presented by the one it was issued to, this token is bei= ng presented by someone it was presented to.=C2=A0 =C2=A0The feeling is clo= se, but not quite the same in either development or assumptions. =C2=A0-- J= ustin =C2=A0/ Sent from my phone / -------- Original message -------- From: Bill Mills =20 Date: 03/26/2015 2:24 PM (GMT-06:00)=20 To: Justin Richer , "" =20 Subject: Re: [OAUTH-WG] Token Chaining Use Case So why can't the access tok= ne simply be re-used as a refresh token? =C2=A0Why would it need a new gran= t type at all? =C2=A0 =C2=A0 =C2=A0On Thursday, March 26, 2015 11:31 AM, Ju= stin Richer wrote: =C2=A0As requested after last night=E2= =80=99s informal meeting, here is the token chaining use case that I want t= o see represented in the token swap draft. [ Client ]=C2=A0 ->=C2=A0 [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, with s= copes [A, B, C] in order to call service A, which requires all three scopes= . Service A (an RS) accepts this token since it has its scope, and then nee= ds to call service B in turn, which requires scopes [B, C]. It could just r= e-send the token it got in, AT1, but that would give the downstream RS the = ability to call services with scope [ A ] and it should not be allowed to d= o that. To limit exposure, service A calls a token swap at the AS to create= AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting= a downscoped token based on AT1. Service A then acts as an OAuth client to= call service B, now acting as an RS to service A=E2=80=99s client, and can= fulfill the request. And it=E2=80=99s turtles all the way down: Service B = can also call service C, and now B acts as a client, requesting AT3 with sc= ope [ C ] based on AT2, and sending AT3 to service C. This prevents C from = being able to call B or A, both of which would have been available if AT1 h= ad been passed around. Note that service A or the Client can also request a= downscoped token with [ C ] to call service C directly as well, and C does= n=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It doesn=E2= =80=99t have to do any special processing, doesn=E2=80=99t have to know wha= t=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a to= ken, I get another token based on this to call someone else=E2=80=9D. It=E2= =80=99s also analogous to the refresh token flow, but with access tokens go= ing in and out. I=E2=80=99ve deployed this setup several times in different= service deployments. Even though there is a performance hit in the additio= nal round trips (as Phil brought up in another thread), in these cases the = desire to have the tokens hold least privilege access rights (smallest set = of scopes per service) outweighed any performance hit (which was shown to b= e rather small in practice). What I want is for the token swap draft to define or use a mechanism that a= llows us to do this. I think we can do that pretty easily by adjusting the = token swap syntax and language, and explicitly calling out the semantic pro= cessing portion (the current core of the document) for what it is: a way fo= r a token issuer to communicate to a token service specific actions. At a h= igh level, the spec would be something like: 1. How to swap a token at an AS =C2=A0 1. Send a request to the token endpoint with a new grant type, and a= token (of any type/format/flavor) on the way in =C2=A0 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion =C2=A0 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as= semantics =C2=A0 2. What to do (as an AS/RS) with a JWT with act-as semantics =C2=A0 3. How to create a JWT with on-behalf-of semeantics =C2=A0 4. What to do with a JWT with on-behalf-of-semantics =C2=A0 5. How to possibly represent these semantics with something other th= an a JWT Section 2 uses the syntax from section 1. Other applications, like the one = I laid out above, can use the syntax from section 1 as well. This works for= structured, unstructured, self-generated, cross-domain, within-domain, and= other tokens. =E2=80=94 Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_2988153_2098028161.1427404385133 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The RS calling back to the AS won't be confu= sed, the token it gets would be it's refresh token.  I don't see any r= eason why the AS can't be smart enough to know that a token that looks like= an access token it issued is usable as a refresh token for limited purpose= s or downscoping.  



=
On Thursday, March 26, = 2015 1:46 PM, Donald F. Coffin <donald.coffin@reminetworks.com> wrote= :


-1
 
Although  Justin=E2=80=99= s point might be a bit pre-mature as far as a standards discussion, the mor= e critical reason IMHO is calling the AS=E2=80=99s /Token endpoint with a g= rant_type of =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rat= her than an issued refresh_token (RT) will definitely create a backwards co= mpatibility issue for many implementations.
 
Best regards,
Don<= /div>
Donald F. Coffi= n
Founde= r/CTO
&= nbsp;
RE= MI Networks
2335 Dunwoody Crossing Suite E
Dunwoody, GA 30338-8221
 
Phone:    =   (949) 636-8571
Email:       donald.coffin@reminetworks.com
=
 
=
From: Phil Hunt [ma= ilto:phil.hunt@oracle.com]
Sent: Thursday, March = 26, 2015 4:22 PM
To: Bill Mills
= Cc: <oauth@ietf.org>
Subject: Re: [OA= UTH-WG] Token Chaining Use Case
 
= +1. We all have to change production code when non final specs evolve. = ;
 
=
I particularly don't see this as= a valid argument at the start of a standards discussion. 
=

Phil

On Mar 26, 2015, at 15:13, Bill Mills <wmills_92105@yahoo.com&= gt; wrote:
By definition an access token is becoming a form o= f refresh token.    The "because my implementation didn't do it t= hat way" isn't convincing me.
&n= bsp;
 
<= span style=3D"font-size:10.0pt;">On Thursday, March 26, 2015 12:44 PM, Just= in Richer <jricher@mit.edu<= /a>> wrote:
 


-------- Original message --------From: Bill Mills <wmills_92105@yahoo.com>
Dat= e: 03/26/2015 2:24 PM (GMT-06:00)
To: Justin Richer <= jricher@MIT.EDU>, "<= oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Chaining Use Case
So why can't the access tokne simpl= y be re-used as a refresh token?  Why would it need a new grant type a= t all?
=  
 
 
O= n Thursday, March 26, 2015 11:31 AM, Justin Richer <jricher@MIT.EDU> wrote:
 
<= div>
As requested after last night=E2=80=99s in= formal meeting, here is the token chaining use case that I want to see repr= esented in the token swap draft.


[ Client ]  ->  [ A ] -> [ B ] -> [ C ]
An OAuth client gets an access token AT1= , just like it always would, with scopes [A, B, C] in order to call service= A, which requires all three scopes. Service A (an RS) accepts this token s= ince it has its scope, and then needs to call service B in turn, which requ= ires scopes [B, C]. It could just re-send the token it got in, AT1, but tha= t would give the downstream RS the ability to call services with scope [ A = ] and it should not be allowed to do that. To limit exposure, service A cal= ls a token swap at the AS to create AT2 with scopes [ B, C ], effectively a= cting as an OAuth client requesting a downscoped token based on AT1. Servic= e A then acts as an OAuth client to call service B, now acting as an RS to = service A=E2=80=99s client, and can fulfill the request. And it=E2=80=99s t= urtles all the way down: Service B can also call service C, and now B acts = as a client, requesting AT3 with scope [ C ] based on AT2, and sending AT3 = to service C. This prevents C from being able to call B or A, both of which= would have been available if AT1 had been passed around. Note that service= A or the Client can also request a downscoped token with [ C ] to call ser= vice C directly as well, and C doesn=E2=80=99t have to care how it got ther= e.


In other words, = it lets the client software be very, very dumb. It doesn=E2=80=99t have to = do any special processing, doesn=E2=80=99t have to know what=E2=80=99s in t= he token, it just follows the recipe of =E2=80=9CI got a token, I get anoth= er token based on this to call someone else=E2=80=9D. It=E2=80=99s also ana= logous to the refresh token flow, but with access tokens going in and out. = I=E2=80=99ve deployed this setup several times in different service deploym= ents. Even though there is a performance hit in the additional round trips = (as Phil brought up in another thread), in these cases the desire to have t= he tokens hold least privilege access rights (smallest set of scopes per se= rvice) outweighed any performance hit (which was shown to be rather small i= n practice).

What I want is for the to= ken swap draft to define or use a mechanism that allows us to do this. I th= ink we can do that pretty easily by adjusting the token swap syntax and lan= guage, and explicitly calling out the semantic processing portion (the curr= ent core of the document) for what it is: a way for a token issuer to commu= nicate to a token service specific actions. At a high level, the spec would= be something like:



1. How to swap a token at an AS
 = ; 1. Send a request to the token endpoint with a new grant type, and a toke= n (of any type/format/flavor) on the way in
  2. Get= back a new token in a token response
2. Communicating ac= t as / on behalf of semantics via a JWT assertion
  = 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as semant= ics
  2. What to do (as an AS/RS) with a JWT with ac= t-as semantics
  3. How to create a JWT with on-beha= lf-of semeantics
  4. What to do with a JWT with on-= behalf-of-semantics
  5. How to possibly represent t= hese semantics with something other than a JWT



Section 2 uses the syntax f= rom section 1. Other applications, like the one I laid out above, can use t= he syntax from section 1 as well. This works for structured, unstructured, = self-generated, cross-domain, within-domain, and other tokens.


=E2=80=94 Justin
_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/oauth

 
=
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"https://www.iet= f.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth


<= /div>
------=_Part_2988153_2098028161.1427404385133-- From nobody Thu Mar 26 14:22:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC8E1B2F30 for ; Thu, 26 Mar 2015 14:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.644 X-Spam-Level: X-Spam-Status: No, score=0.644 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, IP_NOT_FRIENDLY=0.334, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 7SqsH54m5o6U for ; Thu, 26 Mar 2015 14:22:11 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 9A21C1B2F15 for ; Thu, 26 Mar 2015 14:22:11 -0700 (PDT) Received: (qmail 23191 invoked by uid 0); 26 Mar 2015 21:22:09 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 26 Mar 2015 21:22:09 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw2 with id 8MMz1q00q2is6CS01MN2rg; Thu, 26 Mar 2015 15:22:07 -0600 X-Authority-Analysis: v=2.1 cv=XvNpZz19 c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=UMhCEPvdHqkA:10 a=emO1SXQWCLwA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8 a=byEDKA3lsUYVMz7Ro3IA:9 a=2_TNgO-q49Jn-_6x:21 a=y8VewMNnMZo1V1jB:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=BFoD-kyHlE8sNxsMTssA:9 a=i1wdbv5qwldVXXe2:21 a=N8TFzrE0BcZ2Szkg:21 a=EfsPPqab1mFJ3mPp:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=ZGT5YclQLzOhVNipbIwXi/RWrs/E1rpa6KB5jZimUV0=; b=BZ8xljLe7wTPmz88Z+qMhf1EUKZEszkzyqi5XJtApek4R2lNWwHS4AB73WQhhXt1JpINcqnK57g641rmIc8VA8RZLw/DTBKZLz+Aqtdi1yBkrph//ihYd/qxU86ANhr4; Received: from [104.176.153.192] (port=52610 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YbFE1-0006Lt-7O; Thu, 26 Mar 2015 15:22:01 -0600 From: "Donald F. Coffin" To: "'Bill Mills'" , "'Phil Hunt'" References: <002a01d06805$fa89e290$ef9da7b0$@reminetworks.com> <979394715.2988154.1427404385148.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <979394715.2988154.1427404385148.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 26 Mar 2015 17:21:56 -0400 Organization: REMI Networks Message-ID: <004401d0680a$e57a65f0$b06f31d0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01D067E9.5E6B5E00" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKXULkK545a8jxuwK2gxWt6ClypdAHc48gmm5KL6UA= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 104.176.153.192 authed with donald.coffin@reminetworks.com} Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:22:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0045_01D067E9.5E6B5E00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bill, =20 Can you clarify your thoughts on the following: =20 * What AS endpoint does the RS call and how does it present the = AT he received? * What is the grant_type value the RS use in the above endpoint = request? * What does the AS do if the AT was issued by another AS (which = is possible using Justin=E2=80=99s use case)? =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 Sent: Thursday, March 26, 2015 5:13 PM To: Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case =20 The RS calling back to the AS won't be confused, the token it gets would = be it's refresh token. I don't see any reason why the AS can't be smart = enough to know that a token that looks like an access token it issued is = usable as a refresh token for limited purposes or downscoping. =20 =20 =20 On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin = = > wrote: =20 -1 =20 Although Justin=E2=80=99s point might be a bit pre-mature as far as a = standards discussion, the more critical reason IMHO is calling the = AS=E2=80=99s /Token endpoint with a grant_type of = =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rather than = an issued refresh_token (RT) will definitely create a backwards = compatibility issue for many implementations. =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: > Subject: Re: [OAUTH-WG] Token Chaining Use Case =20 +1. We all have to change production code when non final specs evolve.=20 =20 I particularly don't see this as a valid argument at the start of a = standards discussion.=20 Phil On Mar 26, 2015, at 15:13, Bill Mills > wrote: By definition an access token is becoming a form of refresh token. = The "because my implementation didn't do it that way" isn't convincing = me. =20 =20 On Thursday, March 26, 2015 12:44 PM, Justin Richer > wrote: =20 Because many implementations (including mine which does support my old = token chaining draft) treat access tokens and refresh tokens separately = in terms of data store and structure. Additionally, the refresh token is = tied to the client and presented by the client. But in this case it's = someone downstream, an RS, presenting the token. So unlike a refresh = token being presented by the one it was issued to, this token is being = presented by someone it was presented to.=20 =20 The feeling is close, but not quite the same in either development or = assumptions. =20 -- Justin =20 / Sent from my phone / -------- Original message -------- From: Bill Mills = >=20 Date: 03/26/2015 2:24 PM (GMT-06:00)=20 To: Justin Richer >, = " >" >=20 Subject: Re: [OAUTH-WG] Token Chaining Use Case=20 So why can't the access tokne simply be re-used as a refresh token? Why = would it need a new grant type at all? =20 =20 =20 On Thursday, March 26, 2015 11:31 AM, Justin Richer > wrote: =20 As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap = draft. [ Client ] -> [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of = =E2=80=9CI got a token, I get another token based on this to call = someone else=E2=80=9D. It=E2=80=99s also analogous to the refresh token = flow, but with access tokens going in and out. I=E2=80=99ve deployed = this setup several times in different service deployments. Even though = there is a performance hit in the additional round trips (as Phil = brought up in another thread), in these cases the desire to have the = tokens hold least privilege access rights (smallest set of scopes per = service) outweighed any performance hit (which was shown to be rather = small in practice). What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for = what it is: a way for a token issuer to communicate to a token service = specific actions. At a high level, the spec would be something like: 1. How to swap a token at an AS 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as = semantics 2. What to do (as an AS/RS) with a JWT with act-as semantics 3. How to create a JWT with on-behalf-of semeantics 4. What to do with a JWT with on-behalf-of-semantics 5. How to possibly represent these semantics with something other than = a JWT Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This = works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens. =E2=80=94 Justin _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_0045_01D067E9.5E6B5E00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Bill,

 

Can you = clarify your thoughts on the following:

 

=C2=B7         = What AS endpoint does the RS call = and how does it present the AT he = received?

=C2=B7         = What is the grant_type value the = RS use in the above endpoint request?

=C2=B7         = What does the AS do if the AT was = issued by another AS (which is possible using Justin=E2=80=99s use = case)?

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO<= /p>

 

REMI = Networks

2335 Dunwoody Crossing Suite = E

Dunwoody, GA = 30338-8221

 

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

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

 

From:<= /b> = Bill Mills [mailto:wmills_92105@yahoo.com]
Sent: Thursday, = March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil = Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = Token Chaining Use Case

 

= The RS calling back to the AS won't be confused, the token it gets would = be it's refresh token.  I don't see any reason why the AS can't be = smart enough to know that a token that looks like an access token it = issued is usable as a refresh token for limited purposes or downscoping. =  

=  

=  

On = Thursday, March 26, 2015 1:46 PM, Donald F. Coffin <donald.coffin@reminetworks= .com> wrote:

 

-1

 

Although =  Justin=E2=80=99s point might be a bit pre-mature as far as a = standards discussion, the more critical reason IMHO is calling the = AS=E2=80=99s /Token endpoint with a grant_type of = =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rather than = an issued refresh_token (RT) will definitely create a backwards = compatibility issue for many = implementations.

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 

REMI = Networks

2335 Dunwoody = Crossing Suite E

Dunwoody, GA = 30338-8221

 

Phone: &nbs= p;    (949) 636-8571

Email: &nbs= p;     donald.coffin@reminetworks.com

 

From: Phil Hunt [mailto:phil.hunt@oracle.com] =
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill = Mills
Cc: <oauth@ietf.org>
Subject: = Re: [OAUTH-WG] Token Chaining Use Case

 

+1. We all have = to change production code when non final specs = evolve. 

 

I particularly = don't see this as a valid argument at the start of a standards = discussion. 


Phil


On Mar 26, = 2015, at 15:13, Bill Mills <wmills_92105@yahoo.com> = wrote:

= By definition an access token is becoming a form of refresh token. =    The "because my implementation didn't do it that = way" isn't convincing me.

=  

=  

On Thursday, March 26, 2015 12:44 PM, Justin Richer <jricher@mit.edu> wrote:

 

Because many = implementations (including mine which does support my old token chaining = draft) treat access tokens and refresh tokens separately in terms of = data store and structure. Additionally, the refresh token is tied to the = client and presented by the client. But in this case it's someone = downstream, an RS, presenting the token. So unlike a refresh token being = presented by the one it was issued to, this token is being presented by = someone it was presented = to. 

 

The feeling is = close, but not quite the same in either development or = assumptions.

 

= -- Justin

=  

= / Sent from my phone /



--------= Original message --------
From: Bill Mills <wmills_92105@yahoo.com>
Date: 03/26/2015 = 2:24 PM (GMT-06:00)
To: Justin Richer <jricher@MIT.EDU>, "<oauth@ietf.org>" <oauth@ietf.org> =
Subject: Re: [OAUTH-WG] Token Chaining Use Case =

= So why can't the access tokne simply be re-used as a refresh token? =  Why would it need a new grant type at all?

=  

=  

=  

On Thursday, March 26, 2015 11:31 AM, Justin Richer <jricher@MIT.EDU> wrote:

 

As requested = after last night=E2=80=99s informal meeting, here is the token chaining = use case that I want to see represented in the token swap = draft.


[ Client ]  ->  [ A ] -> [ B ] -> [ = C ]

An OAuth client gets an access token AT1, just like it always = would, with scopes [A, B, C] in order to call service A, which requires = all three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there.


In other = words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of = =E2=80=9CI got a token, I get another token based on this to call = someone else=E2=80=9D. It=E2=80=99s also analogous to the refresh token = flow, but with access tokens going in and out. I=E2=80=99ve deployed = this setup several times in different service deployments. Even though = there is a performance hit in the additional round trips (as Phil = brought up in another thread), in these cases the desire to have the = tokens hold least privilege access rights (smallest set of scopes per = service) outweighed any performance hit (which was shown to be rather = small in practice).

What I want is for the token swap draft to = define or use a mechanism that allows us to do this. I think we can do = that pretty easily by adjusting the token swap syntax and language, and = explicitly calling out the semantic processing portion (the current core = of the document) for what it is: a way for a token issuer to communicate = to a token service specific actions. At a high level, the spec would be = something like:



1. How to swap a token at an AS
  = 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in
  2. Get back a = new token in a token response
2. Communicating act as / on behalf of = semantics via a JWT assertion
  1. How to create (as an = AS/RS/client/other issuer) a JWT with act-as semantics
  2. What = to do (as an AS/RS) with a JWT with act-as semantics
  3. How to = create a JWT with on-behalf-of semeantics
  4. What to do with a = JWT with on-behalf-of-semantics
  5. How to possibly represent = these semantics with something other than a JWT



Section 2 = uses the syntax from section 1. Other applications, like the one I laid = out above, can use the syntax from section 1 as well. This works for = structured, unstructured, self-generated, cross-domain, within-domain, = and other tokens.


=E2=80=94 = Justin
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

------=_NextPart_000_0045_01D067E9.5E6B5E00-- From psilva@redhat.com Thu Mar 26 14:25:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5891B2F4C for ; Thu, 26 Mar 2015 14:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3QXzXGQmbhOB for ; Thu, 26 Mar 2015 14:25:27 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.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 ED58A1B2F3D for ; Thu, 26 Mar 2015 14:25:26 -0700 (PDT) Received: from zmail12.collab.prod.int.phx2.redhat.com (zmail12.collab.prod.int.phx2.redhat.com [10.5.83.14]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2QLPQB4010638; Thu, 26 Mar 2015 17:25:26 -0400 Date: Thu, 26 Mar 2015 17:25:25 -0400 (EDT) From: Pedro Igor Silva To: Bill Mills Message-ID: <1580024392.3924957.1427405125772.JavaMail.zimbra@redhat.com> In-Reply-To: <979394715.2988154.1427404385148.JavaMail.yahoo@mail.yahoo.com> References: <002a01d06805$fa89e290$ef9da7b0$@reminetworks.com> <979394715.2988154.1427404385148.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.97.6.97] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC41 (Linux)/8.0.6_GA_5922) Thread-Topic: Token Chaining Use Case Thread-Index: IL6yuyb2vM6kdbI//uNO30UoBaVonA== Archived-At: Cc: "Donald F. Coffin" , oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:27:36 -0000 Couldn't be used a specific type of refresh_token ? Instead of using grant_= type=3Drefresh_token use a grant_type=3Durn:ietf:params:oauth:grant_type:re= delegate (or something else) as an extension to refresh token flow ? Regards. Pedro Igor ----- Original Message ----- > From: "Bill Mills" > To: "Donald F. Coffin" , "Phil Hunt" > Cc: oauth@ietf.org > Sent: Thursday, March 26, 2015 6:13:05 PM > Subject: Re: [OAUTH-WG] Token Chaining Use Case >=20 > The RS calling back to the AS won't be confused, the token it gets would = be > it's refresh token. I don't see any reason why the AS can't be smart enou= gh > to know that a token that looks like an access token it issued is usable = as > a refresh token for limited purposes or downscoping. >=20 >=20 >=20 > On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin > wrote: >=20 >=20 > -1 > Although Justin=E2=80=99s point might be a bit pre-mature as far as a sta= ndards > discussion, the more critical reason IMHO is calling the AS=E2=80=99s /To= ken > endpoint with a grant_type of =E2=80=9Crefresh_token=E2=80=9D but providi= ng an issued AT > rather than an issued refresh_token (RT) will definitely create a backwar= ds > compatibility issue for many implementations. > Best regards, > Don > Donald F. Coffin > Founder/CTO > REMI Networks > 2335 Dunwoody Crossing Suite E > Dunwoody, GA 30338-8221 > Phone: (949) 636-8571 > Email: donald.coffin@reminetworks.com > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Thursday, March 26, 2015 4:22 PM > To: Bill Mills > Cc: > Subject: Re: [OAUTH-WG] Token Chaining Use Case > +1. We all have to change production code when non final specs evolve. > I particularly don't see this as a valid argument at the start of a stand= ards > discussion. >=20 > Phil >=20 > On Mar 26, 2015, at 15:13, Bill Mills < wmills_92105@yahoo.com > wrote: >=20 >=20 >=20 > By definition an access token is becoming a form of refresh token. The > "because my implementation didn't do it that way" isn't convincing me. > On Thursday, March 26, 2015 12:44 PM, Justin Richer < jricher@mit.edu > > wrote: > Because many implementations (including mine which does support my old to= ken > chaining draft) treat access tokens and refresh tokens separately in term= s > of data store and structure. Additionally, the refresh token is tied to t= he > client and presented by the client. But in this case it's someone > downstream, an RS, presenting the token. So unlike a refresh token being > presented by the one it was issued to, this token is being presented by > someone it was presented to. > The feeling is close, but not quite the same in either development or > assumptions. > -- Justin > / Sent from my phone / >=20 >=20 > -------- Original message -------- > From: Bill Mills < wmills_92105@yahoo.com > > Date: 03/26/2015 2:24 PM (GMT-06:00) > To: Justin Richer < jricher@MIT.EDU >, "< oauth@ietf.org >" < oauth@ietf.= org > > > Subject: Re: [OAUTH-WG] Token Chaining Use Case > So why can't the access tokne simply be re-used as a refresh token? Why w= ould > it need a new grant type at all? > On Thursday, March 26, 2015 11:31 AM, Justin Richer < jricher@MIT.EDU > > wrote: > As requested after last night=E2=80=99s informal meeting, here is the tok= en chaining > use case that I want to see represented in the token swap draft. >=20 >=20 > [ Client ] -> [ A ] -> [ B ] -> [ C ] >=20 > An OAuth client gets an access token AT1, just like it always would, with > scopes [A, B, C] in order to call service A, which requires all three > scopes. Service A (an RS) accepts this token since it has its scope, and > then needs to call service B in turn, which requires scopes [B, C]. It co= uld > just re-send the token it got in, AT1, but that would give the downstream= RS > the ability to call services with scope [ A ] and it should not be allowe= d > to do that. To limit exposure, service A calls a token swap at the AS to > create AT2 with scopes [ B, C ], effectively acting as an OAuth client > requesting a downscoped token based on AT1. Service A then acts as an OAu= th > client to call service B, now acting as an RS to service A=E2=80=99s clie= nt, and can > fulfill the request. And it=E2=80=99s turtles all the way down: Service B= can also > call service C, and now B acts as a client, requesting AT3 with scope [ C= ] > based on AT2, and sending AT3 to service C. This prevents C from being ab= le > to call B or A, both of which would have been available if AT1 had been > passed around. Note that service A or the Client can also request a > downscoped token with [ C ] to call service C directly as well, and C > doesn=E2=80=99t have to care how it got there. >=20 >=20 > In other words, it lets the client software be very, very dumb. It doesn= =E2=80=99t > have to do any special processing, doesn=E2=80=99t have to know what=E2= =80=99s in the token, > it just follows the recipe of =E2=80=9CI got a token, I get another token= based on > this to call someone else=E2=80=9D. It=E2=80=99s also analogous to the re= fresh token flow, > but with access tokens going in and out. I=E2=80=99ve deployed this setup= several > times in different service deployments. Even though there is a performanc= e > hit in the additional round trips (as Phil brought up in another thread),= in > these cases the desire to have the tokens hold least privilege access rig= hts > (smallest set of scopes per service) outweighed any performance hit (whic= h > was shown to be rather small in practice). >=20 > What I want is for the token swap draft to define or use a mechanism that > allows us to do this. I think we can do that pretty easily by adjusting t= he > token swap syntax and language, and explicitly calling out the semantic > processing portion (the current core of the document) for what it is: a w= ay > for a token issuer to communicate to a token service specific actions. At= a > high level, the spec would be something like: >=20 >=20 >=20 > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a toke= n > (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as > semantics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other than a = JWT >=20 >=20 >=20 > Section 2 uses the syntax from section 1. Other applications, like the on= e I > laid out above, can use the syntax from section 1 as well. This works for > structured, unstructured, self-generated, cross-domain, within-domain, an= d > other tokens. >=20 >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=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 > From nobody Thu Mar 26 14:29:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A151B2F50 for ; Thu, 26 Mar 2015 14:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.633 X-Spam-Level: X-Spam-Status: No, score=0.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 nByiVAS_TteO for ; Thu, 26 Mar 2015 14:29:54 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 9B6D21B2F3D for ; Thu, 26 Mar 2015 14:29:54 -0700 (PDT) Received: (qmail 18352 invoked by uid 0); 26 Mar 2015 21:29:52 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 26 Mar 2015 21:29:52 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw2 with id 8MVj1q00n2is6CS01MVmVo; Thu, 26 Mar 2015 15:29:50 -0600 X-Authority-Analysis: v=2.1 cv=XvNpZz19 c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=UMhCEPvdHqkA:10 a=emO1SXQWCLwA:10 a=20KFwNOVAAAA:8 a=48vgC7mUAAAA:8 a=CjxXgO3LAAAA:8 a=yPCof4ZbAAAA:8 a=gDjYkMfG9zmxRrQsgU4A:9 a=l0YRgQ7hvOVR0ibt:21 a=8ws3xclv8GnwhGqo:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=HIh3feKP3i3dD3aURDz6GUKlK3aO9FfX2vqAkl57WCU=; b=rMUknA4aBxLgsUhTmprvUADPPmY6GWl1/3NhjOCx2yUZw7BRkuIGrErU4gYwTqJgfGOxUD9XRVq3u7X5ancbdZDi9r0g8tho80RA/wWQMxIBuRoHa6adiSl70J6xDcCD; Received: from [104.176.153.192] (port=52698 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YbFLV-0001Bj-FQ; Thu, 26 Mar 2015 15:29:45 -0600 From: "Donald F. Coffin" To: "'Pedro Igor Silva'" , "'Bill Mills'" References: <002a01d06805$fa89e290$ef9da7b0$@reminetworks.com> <979394715.2988154.1427404385148.JavaMail.yahoo@mail.yahoo.com> <1580024392.3924957.1427405125772.JavaMail.zimbra@redhat.com> In-Reply-To: <1580024392.3924957.1427405125772.JavaMail.zimbra@redhat.com> Date: Thu, 26 Mar 2015 17:29:41 -0400 Organization: REMI Networks Message-ID: <005101d0680b$fa30b750$ee9225f0$@reminetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKXULkK545a8jxuwK2gxWt6ClypdAHc48gmAXz8Kg2bhqb8YA== Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 104.176.153.192 authed with donald.coffin@reminetworks.com} Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:29:56 -0000 Pedro, Although the registry could be changed to support the new type format, = how is that any different than adding a new grant_type, such as = grant_type=3Dtoken_swap or grant_type=3Dswap? Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com -----Original Message----- From: Pedro Igor Silva [mailto:psilva@redhat.com]=20 Sent: Thursday, March 26, 2015 5:25 PM To: Bill Mills Cc: Donald F. Coffin; Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case Couldn't be used a specific type of refresh_token ? Instead of using = grant_type=3Drefresh_token use a = grant_type=3Durn:ietf:params:oauth:grant_type:redelegate (or something = else) as an extension to refresh token flow ? Regards. Pedro Igor ----- Original Message ----- > From: "Bill Mills" > To: "Donald F. Coffin" , "Phil Hunt"=20 > > Cc: oauth@ietf.org > Sent: Thursday, March 26, 2015 6:13:05 PM > Subject: Re: [OAUTH-WG] Token Chaining Use Case >=20 > The RS calling back to the AS won't be confused, the token it gets=20 > would be it's refresh token. I don't see any reason why the AS can't=20 > be smart enough to know that a token that looks like an access token=20 > it issued is usable as a refresh token for limited purposes or = downscoping. >=20 >=20 >=20 > On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin=20 > wrote: >=20 >=20 > -1 > Although Justin=E2=80=99s point might be a bit pre-mature as far as a=20 > standards discussion, the more critical reason IMHO is calling the=20 > AS=E2=80=99s /Token endpoint with a grant_type of = =E2=80=9Crefresh_token=E2=80=9D but=20 > providing an issued AT rather than an issued refresh_token (RT) will=20 > definitely create a backwards compatibility issue for many = implementations. > Best regards, > Don > Donald F. Coffin > Founder/CTO > REMI Networks > 2335 Dunwoody Crossing Suite E > Dunwoody, GA 30338-8221 > Phone: (949) 636-8571 > Email: donald.coffin@reminetworks.com > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Thursday, March 26, 2015 4:22 PM > To: Bill Mills > Cc: > Subject: Re: [OAUTH-WG] Token Chaining Use Case > +1. We all have to change production code when non final specs evolve. > I particularly don't see this as a valid argument at the start of a=20 > standards discussion. >=20 > Phil >=20 > On Mar 26, 2015, at 15:13, Bill Mills < wmills_92105@yahoo.com > = wrote: >=20 >=20 >=20 > By definition an access token is becoming a form of refresh token. The = > "because my implementation didn't do it that way" isn't convincing me. > On Thursday, March 26, 2015 12:44 PM, Justin Richer < jricher@mit.edu=20 > > > wrote: > Because many implementations (including mine which does support my old = > token chaining draft) treat access tokens and refresh tokens=20 > separately in terms of data store and structure. Additionally, the=20 > refresh token is tied to the client and presented by the client. But=20 > in this case it's someone downstream, an RS, presenting the token. So=20 > unlike a refresh token being presented by the one it was issued to,=20 > this token is being presented by someone it was presented to. > The feeling is close, but not quite the same in either development or=20 > assumptions. > -- Justin > / Sent from my phone / >=20 >=20 > -------- Original message -------- > From: Bill Mills < wmills_92105@yahoo.com > > Date: 03/26/2015 2:24 PM (GMT-06:00) > To: Justin Richer < jricher@MIT.EDU >, "< oauth@ietf.org >" <=20 > oauth@ietf.org > > > Subject: Re: [OAUTH-WG] Token Chaining Use Case So why can't the=20 > access tokne simply be re-used as a refresh token? Why would it need a = > new grant type at all? > On Thursday, March 26, 2015 11:31 AM, Justin Richer < jricher@MIT.EDU=20 > > > wrote: > As requested after last night=E2=80=99s informal meeting, here is the = token=20 > chaining use case that I want to see represented in the token swap = draft. >=20 >=20 > [ Client ] -> [ A ] -> [ B ] -> [ C ] >=20 > An OAuth client gets an access token AT1, just like it always would,=20 > with scopes [A, B, C] in order to call service A, which requires all=20 > three scopes. Service A (an RS) accepts this token since it has its=20 > scope, and then needs to call service B in turn, which requires scopes = > [B, C]. It could just re-send the token it got in, AT1, but that would = > give the downstream RS the ability to call services with scope [ A ]=20 > and it should not be allowed to do that. To limit exposure, service A=20 > calls a token swap at the AS to create AT2 with scopes [ B, C ],=20 > effectively acting as an OAuth client requesting a downscoped token=20 > based on AT1. Service A then acts as an OAuth client to call service=20 > B, now acting as an RS to service A=E2=80=99s client, and can fulfill = the=20 > request. And it=E2=80=99s turtles all the way down: Service B can also = call=20 > service C, and now B acts as a client, requesting AT3 with scope [ C ] = > based on AT2, and sending AT3 to service C. This prevents C from being = > able to call B or A, both of which would have been available if AT1=20 > had been passed around. Note that service A or the Client can also=20 > request a downscoped token with [ C ] to call service C directly as = well, and C doesn=E2=80=99t have to care how it got there. >=20 >=20 > In other words, it lets the client software be very, very dumb. It=20 > doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t = have to know what=E2=80=99s=20 > in the token, it just follows the recipe of =E2=80=9CI got a token, I = get=20 > another token based on this to call someone else=E2=80=9D. = It=E2=80=99s also analogous=20 > to the refresh token flow, but with access tokens going in and out.=20 > I=E2=80=99ve deployed this setup several times in different service=20 > deployments. Even though there is a performance hit in the additional=20 > round trips (as Phil brought up in another thread), in these cases the = > desire to have the tokens hold least privilege access rights (smallest = > set of scopes per service) outweighed any performance hit (which was = shown to be rather small in practice). >=20 > What I want is for the token swap draft to define or use a mechanism=20 > that allows us to do this. I think we can do that pretty easily by=20 > adjusting the token swap syntax and language, and explicitly calling=20 > out the semantic processing portion (the current core of the document) = > for what it is: a way for a token issuer to communicate to a token=20 > service specific actions. At a high level, the spec would be something = like: >=20 >=20 >=20 > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a=20 > token (of any type/format/flavor) on the way in 2. Get back a new=20 > token in a token response 2. Communicating act as / on behalf of=20 > semantics via a JWT assertion 1. How to create (as an=20 > AS/RS/client/other issuer) a JWT with act-as semantics 2. What to do=20 > (as an AS/RS) with a JWT with act-as semantics 3. How to create a JWT=20 > with on-behalf-of semeantics 4. What to do with a JWT with=20 > on-behalf-of-semantics 5. How to possibly represent these semantics=20 > with something other than a JWT >=20 >=20 >=20 > Section 2 uses the syntax from section 1. Other applications, like the = > one I laid out above, can use the syntax from section 1 as well. This=20 > works for structured, unstructured, self-generated, cross-domain,=20 > within-domain, and other tokens. >=20 >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=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 > From nobody Thu Mar 26 14:50:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC91B2F94 for ; Thu, 26 Mar 2015 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rPcHR2uspIgQ for ; Thu, 26 Mar 2015 14:50:30 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15471B2F93 for ; Thu, 26 Mar 2015 14:50:29 -0700 (PDT) Received: from zmail12.collab.prod.int.phx2.redhat.com (zmail12.collab.prod.int.phx2.redhat.com [10.5.83.14]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t2QLoTWd002013; Thu, 26 Mar 2015 17:50:29 -0400 Date: Thu, 26 Mar 2015 17:50:29 -0400 (EDT) From: Pedro Igor Silva To: "Donald F. Coffin" Message-ID: <556892999.3957506.1427406629379.JavaMail.zimbra@redhat.com> In-Reply-To: <005101d0680b$fa30b750$ee9225f0$@reminetworks.com> References: <002a01d06805$fa89e290$ef9da7b0$@reminetworks.com> <979394715.2988154.1427404385148.JavaMail.yahoo@mail.yahoo.com> <1580024392.3924957.1427405125772.JavaMail.zimbra@redhat.com> <005101d0680b$fa30b750$ee9225f0$@reminetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.97.6.97] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC41 (Linux)/8.0.6_GA_5922) Thread-Topic: Token Chaining Use Case Thread-Index: AQKXULkK545a8jxuwK2gxWt6ClypdAHc48gmAXz8Kg2bhqb8YDz7YZB1 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:50:34 -0000 Hey Donald, I see your point. And yes, they are no really different. However, I think this is pretty much about refreshing tokens. I understand = that in this case the refresh token is not presented by its owner but someo= ne downstream. But you are kind of refreshing a previously issued token. An= d maybe using a specific grant_type when refreshing can help to handle this= case differently considering all its particularities. Regards. Pedro Igor ----- Original Message ----- > From: "Donald F. Coffin" > To: "Pedro Igor Silva" , "Bill Mills" > Cc: "Phil Hunt" , oauth@ietf.org > Sent: Thursday, March 26, 2015 6:29:41 PM > Subject: RE: [OAUTH-WG] Token Chaining Use Case >=20 > Pedro, >=20 > Although the registry could be changed to support the new type format, ho= w is > that any different than adding a new grant_type, such as > grant_type=3Dtoken_swap or grant_type=3Dswap? >=20 > Best regards, > Don > Donald F. Coffin > Founder/CTO >=20 > REMI Networks > 2335 Dunwoody Crossing Suite E > Dunwoody, GA 30338-8221 >=20 > Phone: (949) 636-8571 > Email: donald.coffin@reminetworks.com >=20 > -----Original Message----- > From: Pedro Igor Silva [mailto:psilva@redhat.com] > Sent: Thursday, March 26, 2015 5:25 PM > To: Bill Mills > Cc: Donald F. Coffin; Phil Hunt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Token Chaining Use Case >=20 > Couldn't be used a specific type of refresh_token ? Instead of using > grant_type=3Drefresh_token use a > grant_type=3Durn:ietf:params:oauth:grant_type:redelegate (or something el= se) > as an extension to refresh token flow ? >=20 > Regards. > Pedro Igor >=20 > ----- Original Message ----- > > From: "Bill Mills" > > To: "Donald F. Coffin" , "Phil Hunt" > > > > Cc: oauth@ietf.org > > Sent: Thursday, March 26, 2015 6:13:05 PM > > Subject: Re: [OAUTH-WG] Token Chaining Use Case > >=20 > > The RS calling back to the AS won't be confused, the token it gets > > would be it's refresh token. I don't see any reason why the AS can't > > be smart enough to know that a token that looks like an access token > > it issued is usable as a refresh token for limited purposes or downscop= ing. > >=20 > >=20 > >=20 > > On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin > > wrote: > >=20 > >=20 > > -1 > > Although Justin=E2=80=99s point might be a bit pre-mature as far as a > > standards discussion, the more critical reason IMHO is calling the > > AS=E2=80=99s /Token endpoint with a grant_type of =E2=80=9Crefresh_toke= n=E2=80=9D but > > providing an issued AT rather than an issued refresh_token (RT) will > > definitely create a backwards compatibility issue for many implementati= ons. > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > REMI Networks > > 2335 Dunwoody Crossing Suite E > > Dunwoody, GA 30338-8221 > > Phone: (949) 636-8571 > > Email: donald.coffin@reminetworks.com > > From: Phil Hunt [mailto:phil.hunt@oracle.com] > > Sent: Thursday, March 26, 2015 4:22 PM > > To: Bill Mills > > Cc: > > Subject: Re: [OAUTH-WG] Token Chaining Use Case > > +1. We all have to change production code when non final specs evolve. > > I particularly don't see this as a valid argument at the start of a > > standards discussion. > >=20 > > Phil > >=20 > > On Mar 26, 2015, at 15:13, Bill Mills < wmills_92105@yahoo.com > wrote: > >=20 > >=20 > >=20 > > By definition an access token is becoming a form of refresh token. The > > "because my implementation didn't do it that way" isn't convincing me. > > On Thursday, March 26, 2015 12:44 PM, Justin Richer < jricher@mit.edu > > > > > wrote: > > Because many implementations (including mine which does support my old > > token chaining draft) treat access tokens and refresh tokens > > separately in terms of data store and structure. Additionally, the > > refresh token is tied to the client and presented by the client. But > > in this case it's someone downstream, an RS, presenting the token. So > > unlike a refresh token being presented by the one it was issued to, > > this token is being presented by someone it was presented to. > > The feeling is close, but not quite the same in either development or > > assumptions. > > -- Justin > > / Sent from my phone / > >=20 > >=20 > > -------- Original message -------- > > From: Bill Mills < wmills_92105@yahoo.com > > > Date: 03/26/2015 2:24 PM (GMT-06:00) > > To: Justin Richer < jricher@MIT.EDU >, "< oauth@ietf.org >" < > > oauth@ietf.org > > > > > Subject: Re: [OAUTH-WG] Token Chaining Use Case So why can't the > > access tokne simply be re-used as a refresh token? Why would it need a > > new grant type at all? > > On Thursday, March 26, 2015 11:31 AM, Justin Richer < jricher@MIT.EDU > > > > > wrote: > > As requested after last night=E2=80=99s informal meeting, here is the t= oken > > chaining use case that I want to see represented in the token swap draf= t. > >=20 > >=20 > > [ Client ] -> [ A ] -> [ B ] -> [ C ] > >=20 > > An OAuth client gets an access token AT1, just like it always would, > > with scopes [A, B, C] in order to call service A, which requires all > > three scopes. Service A (an RS) accepts this token since it has its > > scope, and then needs to call service B in turn, which requires scopes > > [B, C]. It could just re-send the token it got in, AT1, but that would > > give the downstream RS the ability to call services with scope [ A ] > > and it should not be allowed to do that. To limit exposure, service A > > calls a token swap at the AS to create AT2 with scopes [ B, C ], > > effectively acting as an OAuth client requesting a downscoped token > > based on AT1. Service A then acts as an OAuth client to call service > > B, now acting as an RS to service A=E2=80=99s client, and can fulfill t= he > > request. And it=E2=80=99s turtles all the way down: Service B can also = call > > service C, and now B acts as a client, requesting AT3 with scope [ C ] > > based on AT2, and sending AT3 to service C. This prevents C from being > > able to call B or A, both of which would have been available if AT1 > > had been passed around. Note that service A or the Client can also > > request a downscoped token with [ C ] to call service C directly as wel= l, > > and C doesn=E2=80=99t have to care how it got there. > >=20 > >=20 > > In other words, it lets the client software be very, very dumb. It > > doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have= to know what=E2=80=99s > > in the token, it just follows the recipe of =E2=80=9CI got a token, I g= et > > another token based on this to call someone else=E2=80=9D. It=E2=80=99s= also analogous > > to the refresh token flow, but with access tokens going in and out. > > I=E2=80=99ve deployed this setup several times in different service > > deployments. Even though there is a performance hit in the additional > > round trips (as Phil brought up in another thread), in these cases the > > desire to have the tokens hold least privilege access rights (smallest > > set of scopes per service) outweighed any performance hit (which was sh= own > > to be rather small in practice). > >=20 > > What I want is for the token swap draft to define or use a mechanism > > that allows us to do this. I think we can do that pretty easily by > > adjusting the token swap syntax and language, and explicitly calling > > out the semantic processing portion (the current core of the document) > > for what it is: a way for a token issuer to communicate to a token > > service specific actions. At a high level, the spec would be something > > like: > >=20 > >=20 > >=20 > > 1. How to swap a token at an AS > > 1. Send a request to the token endpoint with a new grant type, and a > > token (of any type/format/flavor) on the way in 2. Get back a new > > token in a token response 2. Communicating act as / on behalf of > > semantics via a JWT assertion 1. How to create (as an > > AS/RS/client/other issuer) a JWT with act-as semantics 2. What to do > > (as an AS/RS) with a JWT with act-as semantics 3. How to create a JWT > > with on-behalf-of semeantics 4. What to do with a JWT with > > on-behalf-of-semantics 5. How to possibly represent these semantics > > with something other than a JWT > >=20 > >=20 > >=20 > > Section 2 uses the syntax from section 1. Other applications, like the > > one I laid out above, can use the syntax from section 1 as well. This > > works for structured, unstructured, self-generated, cross-domain, > > within-domain, and other tokens. > >=20 > >=20 > > =E2=80=94 Justin > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > >=20 > >=20 > >=20 > >=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 > From nobody Thu Mar 26 15:03:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58E1B2F9C for ; Thu, 26 Mar 2015 15:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 XLK61IEaMNar for ; Thu, 26 Mar 2015 15:03:40 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3121B2FAC for ; Thu, 26 Mar 2015 15:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427407418; bh=VbPYHaDf7Xj9qV4yLXMP9vwg17TDRC6kpR//90YHLxI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=uMwSqdOBW/R+0AaMaoeBhrfdAVcFUMhub9VP7EhaOdYJY9XAjJXEH52M6JoY+xsYEJ77/tu2jz/jYUnHZ6CNcXTNbl0eOMzQUR5Dx+a+dpl2bPIanFJ81BrOJ903LMKjtOrDUn2Iw4PLhjXU4uNjhuG1G7htbaB+/zj6dLUuYEvCpjv80NX6MDv+/50HBrijOFt27dN4DaBY0CdjcDZMteFfBxCKm+NEdzu/AB6zZu8HIvsu/iZlXiZFhWay01UerrZX+PmggEg/xikxLVUp3IyJes60cJh5cy+iS7cxFSt48pJQslKMQibJdm0uUMiGslaJBf2ZWCUp66ZlG+sEbQ== Received: from [98.139.215.141] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 22:03:38 -0000 Received: from [98.139.212.242] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 22:03:38 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 22:03:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 817304.24972.bm@omp1051.mail.bf1.yahoo.com X-YMail-OSG: KR3R_ioVM1n0jkMWuZwe1r64ThGunMYpzqGZ6d.7SNAoXhl3o.Revsxn6r2HQ8_ BC9dJatnOHHkEd3VQmjKk7v7cyz3ovT2aKD8rFxwIkfXisSmb55yK5V7VW8DY7.c3B7frOYYoeBn lPGhuC69H1DXiIAaVnxY6T5dluZ2sGWW_4i_HpkEAS.BnUxgfKafjD8v58hcWdoorAK9MmeRY8OI vPOqQtm4nOqQPe_qvoxTCAcooyzxBpsjPNsheuwdO1z3UsgPfrRLpvuYECn5NDauHsAnjTPNix_X hsCooAHIBRXDMchuvzTRdCbxM0.OSGKPWr94R1uuaqBzfz4g.bNwfqZKR9_qYce.MGLYu4zG6VLF MC92fhpOHiQaUPL.CLDuY7soGHKW0kwU.up6gv4hWO9gZzvKNjfHC3N7ML7ou8.i0PxvTb3opJMn Ta3iuqm_LY8eg2ornJ.qBlBzNixqaBlyqor5izB0BtIJo2oEhb4A1pfJqH951zj7jwyaumXLv0Wz eLS_KgnZaN5b.bR2dE3jQs3TYHX1YeSzH1yHxnZje Received: by 76.13.26.156; Thu, 26 Mar 2015 22:03:38 +0000 Date: Thu, 26 Mar 2015 22:03:37 +0000 (UTC) From: Bill Mills To: Bill Mills , "Donald F. Coffin" , 'Phil Hunt' Message-ID: <2080364038.3010022.1427407417845.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <123611071.2969574.1427405738183.JavaMail.yahoo@mail.yahoo.com> References: <004401d0680a$e57a65f0$b06f31d0$@reminetworks.com> <123611071.2969574.1427405738183.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3010021_1703895099.1427407417816" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:03:43 -0000 ------=_Part_3010021_1703895099.1427407417816 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Again, I don't think requiring a call out to an internal token reissuer is = a general solution. =C2=A0That said... The RS calls the token endpoint treating the AT as a refresh token in all c= ases and using the refresh_token grant type. =C2=A0Desired scope is specifi= ed by the RS. =C2=A0It's not in spec if there are derivative internal scope= s not in the original scope list though. =C2=A0This doesn't support interna= l scopes for partitioning that the AS doesn't know about.=20 An internal AS providing chaining would need to understand the AT just as t= he RS does, and treat it as a refresh token. -bill On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin wrote: =20 #yiv8232628268 -- filtered {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 = 2 2 4;}#yiv8232628268 filtered {font-family:Wingdings;panose-1:5 0 0 0 0 0 = 0 0 0 0;}#yiv8232628268 filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8232628= 268 filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv823262= 8268 filtered {font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv823262= 8268 filtered {panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv8232628268 p.yiv8232628268= MsoNormal, #yiv8232628268 li.yiv8232628268MsoNormal, #yiv8232628268 div.yiv= 8232628268MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yi= v8232628268 a:link, #yiv8232628268 span.yiv8232628268MsoHyperlink {color:bl= ue;text-decoration:underline;}#yiv8232628268 a:visited, #yiv8232628268 span= .yiv8232628268MsoHyperlinkFollowed {color:purple;text-decoration:underline;= }#yiv8232628268 p.yiv8232628268MsoListParagraph, #yiv8232628268 li.yiv82326= 28268MsoListParagraph, #yiv8232628268 div.yiv8232628268MsoListParagraph {ma= rgin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bot= tom:.0001pt;font-size:12.0pt;}#yiv8232628268 p.yiv8232628268msonormal, #yiv= 8232628268 li.yiv8232628268msonormal, #yiv8232628268 div.yiv8232628268msono= rmal {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv8232628268 p.y= iv8232628268msochpdefault, #yiv8232628268 li.yiv8232628268msochpdefault, #y= iv8232628268 div.yiv8232628268msochpdefault {margin-right:0in;margin-left:0= in;font-size:12.0pt;}#yiv8232628268 span.yiv8232628268msohyperlink {}#yiv82= 32628268 span.yiv8232628268msohyperlinkfollowed {}#yiv8232628268 span.yiv82= 32628268emailstyle17 {}#yiv8232628268 p.yiv8232628268msonormal1, #yiv823262= 8268 li.yiv8232628268msonormal1, #yiv8232628268 div.yiv8232628268msonormal1= {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268 span.yi= v8232628268msohyperlink1 {color:blue;text-decoration:underline;}#yiv8232628= 268 span.yiv8232628268msohyperlinkfollowed1 {color:purple;text-decoration:u= nderline;}#yiv8232628268 span.yiv8232628268emailstyle171 {color:windowtext;= font-weight:normal;font-style:normal;text-decoration:none none;}#yiv8232628= 268 p.yiv8232628268msochpdefault1, #yiv8232628268 li.yiv8232628268msochpdef= ault1, #yiv8232628268 div.yiv8232628268msochpdefault1 {margin-right:0in;mar= gin-left:0in;font-size:10.0pt;}#yiv8232628268 span.yiv8232628268EmailStyle2= 7 {color:windowtext;font-weight:normal;font-style:normal;text-decoration:no= ne none;}#yiv8232628268 .yiv8232628268MsoChpDefault {font-size:10.0pt;}#yiv= 8232628268 filtered {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8232628268 div.yiv= 8232628268WordSection1 {}#yiv8232628268 filtered {}#yiv8232628268 filtered = {font-family:Symbol;}#yiv8232628268 filtered {}#yiv8232628268 filtered {fon= t-family:Wingdings;}#yiv8232628268 filtered {font-family:Symbol;}#yiv823262= 8268 filtered {}#yiv8232628268 filtered {font-family:Wingdings;}#yiv8232628= 268 filtered {font-family:Symbol;}#yiv8232628268 filtered {}#yiv8232628268 = filtered {font-family:Wingdings;}#yiv8232628268 ol {margin-bottom:0in;}#yiv= 8232628268 ul {margin-bottom:0in;}#yiv8232628268 Bill, =C2=A0Can you clarif= y your thoughts on the following: =C2=A0=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 What AS endpoint does the RS call and how does it pre= sent the AT he received? =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What is the grant_ty= pe value the RS use in the above endpoint request? =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What does the AS do = if the AT was issued by another AS (which is possible using Justin=E2=80=99= s use case)? =C2=A0Best regards,DonDonald F. CoffinFounder/CTO =C2=A0REMI N= etworks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221 =C2=A0Phone:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571Email:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 donald.coffin@reminetworks.com =C2=A0From: Bill Mills [mailto:= wmills_92105@yahoo.com]=20 Sent: Thursday, March 26, 2015 5:13 PM To: Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case =C2=A0The RS calling back t= o the AS won't be confused, the token it gets would be it's refresh token. = =C2=A0I don't see any reason why the AS can't be smart enough to know that = a token that looks like an access token it issued is usable as a refresh to= ken for limited purposes or downscoping. =C2=A0 =C2=A0 =C2=A0On Thursday, M= arch 26, 2015 1:46 PM, Donald F. Coffin wr= ote: =C2=A0-1=C2=A0Although =C2=A0Justin=E2=80=99s point might be a bit pre= -mature as far as a standards discussion, the more critical reason IMHO is = calling the AS=E2=80=99s /Token endpoint with a grant_type of =E2=80=9Crefr= esh_token=E2=80=9D but providing an issued AT rather than an issued refresh= _token (RT) will definitely create a backwards compatibility issue for many= implementations.=C2=A0Best regards,DonDonald F. CoffinFounder/CTO=C2=A0REM= I Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221=C2=A0Phone:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571Email:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 donald.coffin@reminetworks.com=C2=A0From: Phil Hunt [mailto:ph= il.hunt@oracle.com]=20 Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: Subject: Re: [OAUTH-WG] Token Chaining Use Case=C2=A0+1. We all have to cha= nge production code when non final specs evolve.=C2=A0=C2=A0I particularly = don't see this as a valid argument at the start of a standards discussion.= =C2=A0 Phil On Mar 26, 2015, at 15:13, Bill Mills wrote: By definition an access token is becoming a form of refresh token. =C2=A0 = =C2=A0The "because my implementation didn't do it that way" isn't convincin= g me.=C2=A0=C2=A0On Thursday, March 26, 2015 12:44 PM, Justin Richer wrote:=C2=A0Because many implementations (including mine which = does support my old token chaining draft) treat access tokens and refresh t= okens separately in terms of data store and structure. Additionally, the re= fresh token is tied to the client and presented by the client. But in this = case it's someone downstream, an RS, presenting the token. So unlike a refr= esh token being presented by the one it was issued to, this token is being = presented by someone it was presented to.=C2=A0=C2=A0The feeling is close, = but not quite the same in either development or assumptions.=C2=A0-- Justin= =C2=A0/ Sent from my phone / -------- Original message -------- From: Bill Mills =20 Date: 03/26/2015 2:24 PM (GMT-06:00)=20 To: Justin Richer , "" =20 Subject: Re: [OAUTH-WG] Token Chaining Use Case So why can't the access tok= ne simply be re-used as a refresh token? =C2=A0Why would it need a new gran= t type at all?=C2=A0=C2=A0=C2=A0On Thursday, March 26, 2015 11:31 AM, Justi= n Richer wrote:=C2=A0As requested after last night=E2=80= =99s informal meeting, here is the token chaining use case that I want to s= ee represented in the token swap draft. [ Client ]=C2=A0 ->=C2=A0 [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, with s= copes [A, B, C] in order to call service A, which requires all three scopes= . Service A (an RS) accepts this token since it has its scope, and then nee= ds to call service B in turn, which requires scopes [B, C]. It could just r= e-send the token it got in, AT1, but that would give the downstream RS the = ability to call services with scope [ A ] and it should not be allowed to d= o that. To limit exposure, service A calls a token swap at the AS to create= AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting= a downscoped token based on AT1. Service A then acts as an OAuth client to= call service B, now acting as an RS to service A=E2=80=99s client, and can= fulfill the request. And it=E2=80=99s turtles all the way down: Service B = can also call service C, and now B acts as a client, requesting AT3 with sc= ope [ C ] based on AT2, and sending AT3 to service C. This prevents C from = being able to call B or A, both of which would have been available if AT1 h= ad been passed around. Note that service A or the Client can also request a= downscoped token with [ C ] to call service C directly as well, and C does= n=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It doesn=E2= =80=99t have to do any special processing, doesn=E2=80=99t have to know wha= t=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a to= ken, I get another token based on this to call someone else=E2=80=9D. It=E2= =80=99s also analogous to the refresh token flow, but with access tokens go= ing in and out. I=E2=80=99ve deployed this setup several times in different= service deployments. Even though there is a performance hit in the additio= nal round trips (as Phil brought up in another thread), in these cases the = desire to have the tokens hold least privilege access rights (smallest set = of scopes per service) outweighed any performance hit (which was shown to b= e rather small in practice). What I want is for the token swap draft to define or use a mechanism that a= llows us to do this. I think we can do that pretty easily by adjusting the = token swap syntax and language, and explicitly calling out the semantic pro= cessing portion (the current core of the document) for what it is: a way fo= r a token issuer to communicate to a token service specific actions. At a h= igh level, the spec would be something like: 1. How to swap a token at an AS =C2=A0 1. Send a request to the token endpoint with a new grant type, and a= token (of any type/format/flavor) on the way in =C2=A0 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion =C2=A0 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as= semantics =C2=A0 2. What to do (as an AS/RS) with a JWT with act-as semantics =C2=A0 3. How to create a JWT with on-behalf-of semeantics =C2=A0 4. What to do with a JWT with on-behalf-of-semantics =C2=A0 5. How to possibly represent these semantics with something other th= an a JWT Section 2 uses the syntax from section 1. Other applications, like the one = I laid out above, can use the syntax from section 1 as well. This works for= structured, unstructured, self-generated, cross-domain, within-domain, and= other tokens. =E2=80=94 Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth=C2=A0 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 ------=_Part_3010021_1703895099.1427407417816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Again, I don't think requiring a call out to an internal t= oken reissuer is a general solution.  That said...

The RS calls the token= endpoint treating the AT as a refresh token in all cases and using the ref= resh_token grant type.  Desired scope is specified by the RS.  It= 's not in spec if there are derivative internal scopes not in the original = scope list though.  This doesn't support internal scopes for partition= ing that the AS doesn't know about.

An internal AS providi= ng chaining would need to understand the AT just as the RS does, and treat = it as a refresh token.

-bill

On Thursday, M= arch 26, 2015 2:22 PM, Donald F. Coffin <donald.coffin@reminetworks.com&= gt; wrote:


Bill,
 
Can you clarify your= thoughts on the following:
 
= =C2=B7       = ;  What AS endpoint does the RS = call and how does it present the AT he received?

=C2=B7         <= /span>What is the grant_type value the RS use in th= e above endpoint request?

=C2=B7 =         What does the AS do if the AT was issued by another AS (which is poss= ible using Justin=E2=80=99s use case)?
 
Best regards,
Don
=
Donald F. Coffin
Founder/CTO=
 =
REMI Ne= tworks
2= 335 Dunwoody Crossing Suite E
Dunwoody, GA 30338-8221
 
Phone:      = (949) 636-8571
Email:       donald.coffin@reminetworks.com
 
From: Bill Mills [mailto:wmi= lls_92105@yahoo.com]
Sent: Thursday, March 26, 20= 15 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re= : [OAUTH-WG] Token Chaining Use Case
 
The = RS calling back to the AS won't be confused, the token it gets would be it'= s refresh token.  I don't see any reason why the AS can't be smart eno= ugh to know that a token that looks like an access token it issued is usabl= e as a refresh token for limited purposes or downscoping.  
<= span style=3D"font-size:9.0pt;">  
 
On Thursday, March 26, 2015 1:46 PM, Donald F. Coffi= n <donald.coffin@reminetworks.com> wrote:=
 
-1
 
Although  Justin=E2=80=99s= point might be a bit pre-mature as far as a standards discussion, the more= critical reason IMHO is calling the AS=E2=80=99s /Token endpoint with a gr= ant_type of =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rath= er than an issued refresh_token (RT) will definitely create a backwards com= patibility issue for many implementations.
&= nbsp;
Best regards,
<= div>
Don
=
Donald F. Coffin
Founder/CTO
 
REMI Net= works
2335 Dunwoody Crossing Suite E<= /div>
Dunwoody, GA 30338-8221
 
Phone:    &= nbsp; (949) 636-8571
Email:   = ;    donald.coffin@reminetwor= ks.com
 
<= /div>
From: Phil Hunt [<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:phil.hunt@oracle.com" t= arget=3D"_blank" href=3D"mailto:phil.hunt@oracle.com">mailto:phil.hunt@orac= le.com]
Sent: Thursday, March 26, 2015 4:22 P= M
To: Bill Mills
Cc: <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Chaining Use Case
 
+1. We all have to change production code when non= final specs evolve. 
 =
I particularly don't see this as= a valid argument at the start of a standards discussion. 

Phil

On= Mar 26, 2015, at 15:13, Bill Mills <wmills_92105@yahoo.com> wrote:
<= /div>
By definition an access token is becoming a form of refr= esh token.    The "because my implementation didn't do it that wa= y" isn't convincing me.
 
=
 =
On Thursd= ay, March 26, 2015 12:44 PM, Justin Richer <jricher@mit.edu> wrote:
 
=
<= div class=3D"yiv8232628268MsoNormal" style=3D"background:white;">Because many implementations (including mine which does support my o= ld token chaining draft) treat access tokens and refresh tokens separately = in terms of data store and structure. Additionally, the refresh token is ti= ed to the client and presented by the client. But in this case it's someone= downstream, an RS, presenting the token. So unlike a refresh token being p= resented by the one it was issued to, this token is being presented by some= one it was presented to. 
&n= bsp;
The feeling is close, but no= t quite the same in either development or assumptions.
 
-- Justin
 
/ Sent from my phone /


-------- Original message --------
From: Bill Mills <wmills_92105@yahoo.com>
Date: 03= /26/2015 2:24 PM (GMT-06:00)
To: Justin Richer <jricher@MIT.EDU>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Chaining Use Case
So why can't the access tokne = simply be re-used as a refresh token?  Why would it need a new grant t= ype at all?
&n= bsp;
 
 
On Thursday, March 26, 2015 11:31 AM, Justin Richer <jricher@MIT.EDU> wrote:
 
As requested after last night=E2=80=99s informal mee= ting, here is the token chaining use case that I want to see represented in= the token swap draft.


[ Client ]  ->  [ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just lik= e it always would, with scopes [A, B, C] in order to call service A, which = requires all three scopes. Service A (an RS) accepts this token since it ha= s its scope, and then needs to call service B in turn, which requires scope= s [B, C]. It could just re-send the token it got in, AT1, but that would gi= ve the downstream RS the ability to call services with scope [ A ] and it s= hould not be allowed to do that. To limit exposure, service A calls a token= swap at the AS to create AT2 with scopes [ B, C ], effectively acting as a= n OAuth client requesting a downscoped token based on AT1. Service A then a= cts as an OAuth client to call service B, now acting as an RS to service A= =E2=80=99s client, and can fulfill the request. And it=E2=80=99s turtles al= l the way down: Service B can also call service C, and now B acts as a clie= nt, requesting AT3 with scope [ C ] based on AT2, and sending AT3 to servic= e C. This prevents C from being able to call B or A, both of which would ha= ve been available if AT1 had been passed around. Note that service A or the= Client can also request a downscoped token with [ C ] to call service C di= rectly as well, and C doesn=E2=80=99t have to care how it got there.


In other words, it lets t= he client software be very, very dumb. It doesn=E2=80=99t have to do any sp= ecial processing, doesn=E2=80=99t have to know what=E2=80=99s in the token,= it just follows the recipe of =E2=80=9CI got a token, I get another token = based on this to call someone else=E2=80=9D. It=E2=80=99s also analogous to= the refresh token flow, but with access tokens going in and out. I=E2=80= =99ve deployed this setup several times in different service deployments. E= ven though there is a performance hit in the additional round trips (as Phi= l brought up in another thread), in these cases the desire to have the toke= ns hold least privilege access rights (smallest set of scopes per service) = outweighed any performance hit (which was shown to be rather small in pract= ice).

What I want is for the token swa= p draft to define or use a mechanism that allows us to do this. I think we = can do that pretty easily by adjusting the token swap syntax and language, = and explicitly calling out the semantic processing portion (the current cor= e of the document) for what it is: a way for a token issuer to communicate = to a token service specific actions. At a high level, the spec would be som= ething like:



1. How to swap a token at an AS
  1. Se= nd a request to the token endpoint with a new grant type, and a token (of a= ny type/format/flavor) on the way in
  2. Get back a= new token in a token response
2. Communicating act as / = on behalf of semantics via a JWT assertion
  1. How = to create (as an AS/RS/client/other issuer) a JWT with act-as semantics
  2. What to do (as an AS/RS) with a JWT with act-as se= mantics
  3. How to create a JWT with on-behalf-of s= emeantics
  4. What to do with a JWT with on-behalf-= of-semantics
  5. How to possibly represent these se= mantics with something other than a JWT



Section 2 uses the syntax from sect= ion 1. Other applications, like the one I laid out above, can use the synta= x from section 1 as well. This works for structured, unstructured, self-gen= erated, cross-domain, within-domain, and other tokens.

=E2=80=94 Justin
____= ___________________________________________
OAuth mailing= list
OAuth@ie= tf.org
https://www.iet= f.org/mailman/listinfo/oauth
=
 =
__= _____________________________________________
OAuth maili= ng list
OAuth@= ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
 


------=_Part_3010021_1703895099.1427407417816-- From nobody Thu Mar 26 15:16:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075E41A014C for ; Thu, 26 Mar 2015 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Q0GLSu9xBfNK for ; Thu, 26 Mar 2015 15:15:56 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E171A0174 for ; Thu, 26 Mar 2015 15:15:55 -0700 (PDT) Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKVRSFG9hxmmQVCnnmucCWmNQOgCHKlKFh@postini.com; Thu, 26 Mar 2015 15:15:55 PDT Received: by igbqf9 with SMTP id qf9so5080541igb.1 for ; Thu, 26 Mar 2015 15:15:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Twb/EQDAkwaJBEbiFOyR9h5k3QuImf+VZZzLd6GS4gU=; b=TUnxKyc97yLWt9VIcarC9WODewx5yiCezopC0e5iL/0vSh/Pf2Mxtnb6pY3aTNi5Mq I+6FhOQsiIIHicellxVJckjOxLWSVMi8+9wrUztufAeYJCpJYsDzb6ixWH/4ELEatQEe bEhkco1nZgGg2DGhBsU+YNM/KTmmDnEPuzwoQxN2p+8NqMZBMIYkEpyp8AlY8x4C3/2v F1okOxIdtMngCxYIOsbz5DUqkyhTWM0iXyzx9eA79ZqNt8qx8A6ICBTzSkLOS4Mt7qn/ pTYz9Zl/ANsq1swSHN0mdQDiCKdAWwUdXbx5bxbj95W2v/aaAfw/p/n4VqhlwXkSnczt 2IrQ== X-Gm-Message-State: ALoCoQkevAZEvOYITwoIKg+7TtDtU6NYKbujuomRK74K00/+kwY1UyVhbiLb7D3nCHDN1PrZBAlLSxYJrJJbntlI8zffUplcM4FgcSLuySVrVKpgyXig6Kma6RA61drr2tM39JPVo0Yj X-Received: by 10.107.135.212 with SMTP id r81mr25305075ioi.38.1427408154706; Thu, 26 Mar 2015 15:15:54 -0700 (PDT) X-Received: by 10.107.135.212 with SMTP id r81mr25305063ioi.38.1427408154560; Thu, 26 Mar 2015 15:15:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.7.193 with HTTP; Thu, 26 Mar 2015 15:15:23 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 26 Mar 2015 17:15:23 -0500 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a113ec85a009ad20512385c21 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:15:59 -0000 --001a113ec85a009ad20512385c21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This kind of token exchange might involve exchanges other than swapping an AT for another AT (and downscoping it). It might be an AT for a structured JWT specifically targeted at one of the the particular services that the original RS needs to call. Or an AT might be exchanged for a SAML assertion to use with legacy SOAP serveries. A good general token exchange mechanism enables lots of variations of cases like the one Justin mentioned. And more. In fact, I think downscoping might be a minority use case where what token exchange is often need for is translating tokens from what you have into what the resource you need to call can deal with. There need to be ways for the caller to tell the AS about the token it's asking for - by type or by the address/identifier of where it'll be used. There needs to be ways for the caller to authenticate to the AS. And there needs to be some way of expressing this delegation thing (though I'm still not totally convinced it couldn't be just the token is about the user/principal and the caller/client of the exchange is who is being delegated to). I realize few (approaching zero) people have or are going to read it but I have endeavored to cover all these things in the http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's an early draft so not without it some rough edges but can provide some guidance on what is needed and offers some protocol syntax for expressing it. I believe Justin's use case would be covered by it (defining a specific token type URI for an OAuth access token issued by the AS in question might be needed) as are many others. On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer wrote: > As requested after last night=E2=80=99s informal meeting, here is the tok= en > chaining use case that I want to see represented in the token swap draft. > > > [ Client ] -> [ A ] -> [ B ] -> [ C ] > > An OAuth client gets an access token AT1, just like it always would, with > scopes [A, B, C] in order to call service A, which requires all three > scopes. Service A (an RS) accepts this token since it has its scope, and > then needs to call service B in turn, which requires scopes [B, C]. It > could just re-send the token it got in, AT1, but that would give the > downstream RS the ability to call services with scope [ A ] and it should > not be allowed to do that. To limit exposure, service A calls a token swa= p > at the AS to create AT2 with scopes [ B, C ], effectively acting as an > OAuth client requesting a downscoped token based on AT1. Service A then > acts as an OAuth client to call service B, now acting as an RS to service > A=E2=80=99s client, and can fulfill the request. And it=E2=80=99s turtles= all the way down: > Service B can also call service C, and now B acts as a client, requesting > AT3 with scope [ C ] based on AT2, and sending AT3 to service C. This > prevents C from being able to call B or A, both of which would have been > available if AT1 had been passed around. Note that service A or the Clien= t > can also request a downscoped token with [ C ] to call service C directly > as well, and C doesn=E2=80=99t have to care how it got there. > > > In other words, it lets the client software be very, very dumb. It doesn= =E2=80=99t > have to do any special processing, doesn=E2=80=99t have to know what=E2= =80=99s in the > token, it just follows the recipe of =E2=80=9CI got a token, I get anothe= r token > based on this to call someone else=E2=80=9D. It=E2=80=99s also analogous = to the refresh > token flow, but with access tokens going in and out. I=E2=80=99ve deploye= d this > setup several times in different service deployments. Even though there i= s > a performance hit in the additional round trips (as Phil brought up in > another thread), in these cases the desire to have the tokens hold least > privilege access rights (smallest set of scopes per service) outweighed a= ny > performance hit (which was shown to be rather small in practice). > > What I want is for the token swap draft to define or use a mechanism that > allows us to do this. I think we can do that pretty easily by adjusting t= he > token swap syntax and language, and explicitly calling out the semantic > processing portion (the current core of the document) for what it is: a w= ay > for a token issuer to communicate to a token service specific actions. At= a > high level, the spec would be something like: > > > > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a > token (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as > semantics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other than = a > JWT > > > > Section 2 uses the syntax from section 1. Other applications, like the on= e > I laid out above, can use the syntax from section 1 as well. This works f= or > structured, unstructured, self-generated, cross-domain, within-domain, an= d > other tokens. > > > =E2=80=94 Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113ec85a009ad20512385c21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This kind of token exchange might involve exchan= ges other than swapping an AT for another AT (and downscoping it). It might= be an AT for a structured JWT specifically targeted at one of the the part= icular services that the original RS needs to call. Or an AT might be excha= nged for a SAML assertion to use with legacy SOAP serveries.=C2=A0 A good g= eneral token exchange mechanism enables lots of variations of cases like th= e one Justin mentioned. And more. In fact, I think downscoping might be a m= inority use case where what token exchange is often need for is translating= tokens from what you have into what the resource you need to call can deal= with.

There need to be ways for the caller to tell the AS ab= out the token it's asking for - by type or by the address/identifier of= where it'll be used. There needs to be ways for the caller to authenti= cate to the AS. And there needs to be some way of expressing this delegatio= n thing (though I'm still not totally convinced it couldn't be just= the token is about the user/principal and the caller/client of the exchang= e is who is being delegated to).

I realize few (approaching z= ero) people have or are going to read it but I have endeavored to cover all= these things in the http://tools.ietf.org/html/draft-campbell-oa= uth-sts-02 draft. It's an early draft so not without it some rough = edges but can provide some guidance on what is needed and offers some proto= col syntax for expressing it. I believe Justin's use case would be cove= red by it (defining a specific token type URI for an OAuth access token iss= ued by the AS in question might be needed) as are many others.

On Thu, Mar 26, 2015= at 1:31 PM, Justin Richer <jricher@mit.edu> wrote:
As requested after last night=E2=80=99s informal me= eting, here is the token chaining use case that I want to see represented i= n the token swap draft.


[ Client ]=C2=A0 ->=C2=A0 =C2=A0[ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just like it always would, with s= copes [A, B, C] in order to call service A, which requires all three scopes= . Service A (an RS) accepts this token since it has its scope, and then nee= ds to call service B in turn, which requires scopes [B, C]. It could just r= e-send the token it got in, AT1, but that would give the downstream RS the = ability to call services with scope [ A ] and it should not be allowed to d= o that. To limit exposure, service A calls a token swap at the AS to create= AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting= a downscoped token based on AT1. Service A then acts as an OAuth client to= call service B, now acting as an RS to service A=E2=80=99s client, and can= fulfill the request. And it=E2=80=99s turtles all the way down: Service B = can also call service C, and now B acts as a client, requesting AT3 with sc= ope [ C ] based on AT2, and sending AT3 to service C. This prevents C from = being able to call B or A, both of which would have been available if AT1 h= ad been passed around. Note that service A or the Client can also request a= downscoped token with [ C ] to call service C directly as well, and C does= n=E2=80=99t have to care how it got there.


In other words, it lets the client software be very, very dumb. It doesn=E2= =80=99t have to do any special processing, doesn=E2=80=99t have to know wha= t=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a to= ken, I get another token based on this to call someone else=E2=80=9D. It=E2= =80=99s also analogous to the refresh token flow, but with access tokens go= ing in and out. I=E2=80=99ve deployed this setup several times in different= service deployments. Even though there is a performance hit in the additio= nal round trips (as Phil brought up in another thread), in these cases the = desire to have the tokens hold least privilege access rights (smallest set = of scopes per service) outweighed any performance hit (which was shown to b= e rather small in practice).

What I want is for the token swap draft to define or use a mechanism that a= llows us to do this. I think we can do that pretty easily by adjusting the = token swap syntax and language, and explicitly calling out the semantic pro= cessing portion (the current core of the document) for what it is: a way fo= r a token issuer to communicate to a token service specific actions. At a h= igh level, the spec would be something like:



1. How to swap a token at an AS
=C2=A0 1. Send a request to the token endpoint with a new grant type, and a= token (of any type/format/flavor) on the way in
=C2=A0 2. Get back a new token in a token response
2. Communicating act as / on behalf of semantics via a JWT assertion
=C2=A0 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as= semantics
=C2=A0 2. What to do (as an AS/RS) with a JWT with act-as semantics
=C2=A0 3. How to create a JWT with on-behalf-of semeantics
=C2=A0 4. What to do with a JWT with on-behalf-of-semantics
=C2=A0 5. How to possibly represent these semantics with something other th= an a JWT



Section 2 uses the syntax from section 1. Other applications, like the one = I laid out above, can use the syntax from section 1 as well. This works for= structured, unstructured, self-generated, cross-domain, within-domain, and= other tokens.


=C2=A0=E2=80=94 Justin

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


--001a113ec85a009ad20512385c21-- From nobody Thu Mar 26 15:33:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D5E1A0120 for ; Thu, 26 Mar 2015 15:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.634 X-Spam-Level: X-Spam-Status: No, score=0.634 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, IP_NOT_FRIENDLY=0.334, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 BiNsdBL-0SpX for ; Thu, 26 Mar 2015 15:33:20 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id B9C141A00EF for ; Thu, 26 Mar 2015 15:33:20 -0700 (PDT) Received: (qmail 28876 invoked by uid 0); 26 Mar 2015 22:33:19 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 26 Mar 2015 22:33:19 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with id 8UZB1q00N2is6CS01UZEqx; Thu, 26 Mar 2015 22:33:17 -0600 X-Authority-Analysis: v=2.1 cv=BvsOn+n5 c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=UMhCEPvdHqkA:10 a=emO1SXQWCLwA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8 a=0FrQQII1l7uOYUxC-2cA:9 a=ZaK7BmBDPTdcbAGN:21 a=nsKcO1OHwCGYQEJR:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=VCahQnVi8smzENXVyPcA:9 a=0PLpSqU1ZD4ZXCYS:21 a=95SrN6NHzm5aEVnb:21 a=4iLhkP66w_lrHZw-:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=4SpSNmouiHp4fDVK0ekac1iRVHjzCgAWVUBsJnzuroA=; b=csSLX5susKckQ9qV2rfpthzQUJ4LF3AhULD7MhquFSFHZdXPg9OEBG0U1n14TcXmIs2zM+0jxQvJIBn/hbAiqyVDQMLKHWgEZMmBBRO2xRun3pq5dZe16ab8IIcguTBy; Received: from [104.176.153.192] (port=53032 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YbGKu-0005t8-9L; Thu, 26 Mar 2015 16:33:13 -0600 From: "Donald F. Coffin" To: "'Bill Mills'" , "'Phil Hunt'" References: <004401d0680a$e57a65f0$b06f31d0$@reminetworks.com> <123611071.2969574.1427405738183.JavaMail.yahoo@mail.yahoo.com> <2080364038.3010022.1427407417845.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <2080364038.3010022.1427407417845.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 26 Mar 2015 18:33:07 -0400 Organization: REMI Networks Message-ID: <006a01d06814$d74c7090$85e551b0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01D067F3.505E1000" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKMvJM6kEAqGnUvlFNy769xfwR59gLeFZqbAg0v/n2bj1I2kA== Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 104.176.153.192 authed with donald.coffin@reminetworks.com} Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:33:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006B_01D067F3.505E1000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bill, =20 Thanks for the clarification. =20 How do you propose the AS deal with the following RFC6749 Section 6. = Refreshing an Access Token requirement? =20 Scope OPTIONAL. The scope of the access request as described by Section 3.3. = The requested scope MUST NOT include any scope not originally granted by = the resource owner, and if omitted is treated as equal to the scope = originally granted by the resource owner. =20 The authorization server MAY issue a new refresh token, in which case = the client MUST discard the old refresh token and replace it with the = new refresh token. The authorization server MAY revoke the old refresh = token after issuing a new refresh token to the client. If a new refresh = token is issued, the refresh scope MUST be identical to that of the = refresh token included by the client in the request. =20 Since the RS is attempting to obtain a new AT, what happens to the old = AT that was submitted as a refresh_token, should the AS issue a new = refresh_token, which it is allowed to do as stated above? Since this = was really an AT, doesn=E2=80=99t this mean the RS and issuing AS will = be required to REVOKE the AT? If the AS is not the AS that issued the = original AT and there is no scope=3D value in the request, how does it = ensure the request isn=E2=80=99t asking for more access than was granted = by the granting AS? =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 Sent: Thursday, March 26, 2015 6:04 PM To: Bill Mills; Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case =20 =20 Again, I don't think requiring a call out to an internal token reissuer = is a general solution. That said... =20 The RS calls the token endpoint treating the AT as a refresh token in = all cases and using the refresh_token grant type. Desired scope is = specified by the RS. It's not in spec if there are derivative internal = scopes not in the original scope list though. This doesn't support = internal scopes for partitioning that the AS doesn't know about. =20 An internal AS providing chaining would need to understand the AT just = as the RS does, and treat it as a refresh token. =20 -bill =20 On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin = = > wrote: =20 Bill, =20 Can you clarify your thoughts on the following: =20 * What AS endpoint does the RS call and how does it present the = AT he received? * What is the grant_type value the RS use in the above endpoint = request? * What does the AS do if the AT was issued by another AS (which = is possible using Justin=E2=80=99s use case)? =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 Sent: Thursday, March 26, 2015 5:13 PM To: Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org =20 Subject: Re: [OAUTH-WG] Token Chaining Use Case =20 The RS calling back to the AS won't be confused, the token it gets would = be it's refresh token. I don't see any reason why the AS can't be smart = enough to know that a token that looks like an access token it issued is = usable as a refresh token for limited purposes or downscoping. =20 =20 =20 On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin = = > wrote: =20 -1 =20 Although Justin=E2=80=99s point might be a bit pre-mature as far as a = standards discussion, the more critical reason IMHO is calling the = AS=E2=80=99s /Token endpoint with a grant_type of = =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rather than = an issued refresh_token (RT) will definitely create a backwards = compatibility issue for many implementations. =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: > Subject: Re: [OAUTH-WG] Token Chaining Use Case =20 +1. We all have to change production code when non final specs evolve.=20 =20 I particularly don't see this as a valid argument at the start of a = standards discussion.=20 Phil On Mar 26, 2015, at 15:13, Bill Mills > wrote: By definition an access token is becoming a form of refresh token. = The "because my implementation didn't do it that way" isn't convincing = me. =20 =20 On Thursday, March 26, 2015 12:44 PM, Justin Richer > wrote: =20 Because many implementations (including mine which does support my old = token chaining draft) treat access tokens and refresh tokens separately = in terms of data store and structure. Additionally, the refresh token is = tied to the client and presented by the client. But in this case it's = someone downstream, an RS, presenting the token. So unlike a refresh = token being presented by the one it was issued to, this token is being = presented by someone it was presented to.=20 =20 The feeling is close, but not quite the same in either development or = assumptions. =20 -- Justin =20 / Sent from my phone / -------- Original message -------- From: Bill Mills = >=20 Date: 03/26/2015 2:24 PM (GMT-06:00)=20 To: Justin Richer >, = " >" >=20 Subject: Re: [OAUTH-WG] Token Chaining Use Case=20 So why can't the access tokne simply be re-used as a refresh token? Why = would it need a new grant type at all? =20 =20 =20 On Thursday, March 26, 2015 11:31 AM, Justin Richer > wrote: =20 As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap = draft. [ Client ] -> [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of = =E2=80=9CI got a token, I get another token based on this to call = someone else=E2=80=9D. It=E2=80=99s also analogous to the refresh token = flow, but with access tokens going in and out. I=E2=80=99ve deployed = this setup several times in different service deployments. Even though = there is a performance hit in the additional round trips (as Phil = brought up in another thread), in these cases the desire to have the = tokens hold least privilege access rights (smallest set of scopes per = service) outweighed any performance hit (which was shown to be rather = small in practice). What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for = what it is: a way for a token issuer to communicate to a token service = specific actions. At a high level, the spec would be something like: 1. How to swap a token at an AS 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as = semantics 2. What to do (as an AS/RS) with a JWT with act-as semantics 3. How to create a JWT with on-behalf-of semeantics 4. What to do with a JWT with on-behalf-of-semantics 5. How to possibly represent these semantics with something other than = a JWT Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This = works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens. =E2=80=94 Justin _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 =20 ------=_NextPart_000_006B_01D067F3.505E1000 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Bill,

 

Thanks for = the clarification.

 

How do you = propose the AS deal with the following RFC6749 Section 6. Refreshing an = Access Token requirement?

 

Scope

OPTIONAL.=C2=A0 The scope of the = access request as described by Section 3.3.=C2=A0 The requested scope = MUST NOT include any scope not originally granted by the resource owner, = and if omitted is treated as equal to the scope originally granted by = the resource owner.

 

The authorization server MAY issue = a new refresh token, in which case the client MUST discard the old = refresh token and replace it with the new refresh token.=C2=A0 The = authorization server MAY revoke the old refresh token after issuing a = new refresh token to the client.=C2=A0 If a new refresh token is issued, = the refresh scope MUST be identical to that of the refresh token = included by the client in the request.

 

Since the = RS is attempting to obtain a new AT, what happens to the old AT that was = submitted as a refresh_token, should the AS issue a new refresh_token, = which it is allowed to do as stated above?=C2=A0 Since this was really = an AT, doesn=E2=80=99t this mean the RS and issuing AS will be required = to REVOKE the AT?=C2=A0 If the AS is not the AS that issued the original = AT and there is no scope=3D value in the request, how does it ensure the = request isn=E2=80=99t asking for more access than was granted by the = granting AS?

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO<= /p>

 

REMI = Networks

2335 Dunwoody Crossing Suite = E

Dunwoody, GA = 30338-8221

 

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

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

 

From:<= /b> = Bill Mills [mailto:wmills_92105@yahoo.com]
Sent: Thursday, = March 26, 2015 6:04 PM
To: Bill Mills; Donald F. Coffin; 'Phil = Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = Token Chaining Use Case

 

=  

= Again, I don't think requiring a call out to an internal token reissuer = is a general solution.  That = said...

=  

= The RS calls the token endpoint treating the AT as a refresh token in = all cases and using the refresh_token grant type.  Desired scope is = specified by the RS.  It's not in spec if there are derivative = internal scopes not in the original scope list though.  This = doesn't support internal scopes for partitioning that the AS doesn't = know about.

=  

= An internal AS providing chaining would need to understand the AT just = as the RS does, and treat it as a refresh = token.

=  

= -bill

=  

On = Thursday, March 26, 2015 2:22 PM, Donald F. Coffin <donald.coffin@reminetworks= .com> wrote:

 

Bill,=

 

Can you clarify = your thoughts on the following:

 

=C2=B7      = ;   What AS = endpoint does the RS call and how does it present the AT he = received?

=C2=B7      = ;   What is the = grant_type value the RS use in the above endpoint = request?

=C2=B7      = ;   What does the = AS do if the AT was issued by another AS (which is possible using = Justin=E2=80=99s use case)?

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 

REMI = Networks

2335 Dunwoody = Crossing Suite E

Dunwoody, GA = 30338-8221

 

Phone: &nbs= p;    (949) 636-8571

Email: &nbs= p;     donald.coffin@reminetworks.com

 

From: Bill Mills [mailto:wmills_92105@yahoo.com]=
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald = F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] Token Chaining Use Case

 

= The RS calling back to the AS won't be confused, the token it gets would = be it's refresh token.  I don't see any reason why the AS can't be = smart enough to know that a token that looks like an access token it = issued is usable as a refresh token for limited purposes or downscoping. =  

=  

=  

On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin <donald.coffin@reminetworks.com> = wrote:

 

-1

 

Although =  Justin=E2=80=99s point might be a bit pre-mature as far as a = standards discussion, the more critical reason IMHO is calling the = AS=E2=80=99s /Token endpoint with a grant_type of = =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rather than = an issued refresh_token (RT) will definitely create a backwards = compatibility issue for many = implementations.

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 

REMI = Networks

2335 Dunwoody = Crossing Suite E

Dunwoody, GA = 30338-8221

 

Phone: &nbs= p;    (949) = 636-8571

Email: &nbs= p;     donald.coffin@reminetworks.com

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: = Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: = <oauth@ietf.org>
Subject: Re: = [OAUTH-WG] Token Chaining Use Case

 

+1. We all have = to change production code when non final specs = evolve. 

 

I particularly = don't see this as a valid argument at the start of a standards = discussion. 

<= p class=3DMsoNormal style=3D'background:white'>
Phil


On Mar 26, = 2015, at 15:13, Bill Mills <wmills_92105@yahoo.com> = wrote:

= By definition an access token is becoming a form of refresh token. =    The "because my implementation didn't do it that = way" isn't convincing me.

=  

=  

On Thursday, March 26, 2015 12:44 PM, Justin Richer <jricher@mit.edu> wrote:

 

Because many = implementations (including mine which does support my old token chaining = draft) treat access tokens and refresh tokens separately in terms of = data store and structure. Additionally, the refresh token is tied to the = client and presented by the client. But in this case it's someone = downstream, an RS, presenting the token. So unlike a refresh token being = presented by the one it was issued to, this token is being presented by = someone it was presented = to. 

 

The feeling is = close, but not quite the same in either development or = assumptions.

 

= -- Justin

=  

= / Sent from my phone /



--------= Original message --------
From: Bill Mills <wmills_92105@yahoo.com>
Date: 03/26/2015 = 2:24 PM (GMT-06:00)
To: Justin Richer <jricher@MIT.EDU>, "<oauth@ietf.org>" <oauth@ietf.org> =
Subject: Re: [OAUTH-WG] Token Chaining Use Case =

= So why can't the access tokne simply be re-used as a refresh token? =  Why would it need a new grant type at all?

=  

=  

=  

On Thursday, March 26, 2015 11:31 AM, Justin Richer <jricher@MIT.EDU> wrote:

 

As requested = after last night=E2=80=99s informal meeting, here is the token chaining = use case that I want to see represented in the token swap = draft.


[ Client ]  ->  [ A ] -> [ B ] -> [ = C ]

An OAuth client gets an access token AT1, just like it always = would, with scopes [A, B, C] in order to call service A, which requires = all three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there.


In other = words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of = =E2=80=9CI got a token, I get another token based on this to call = someone else=E2=80=9D. It=E2=80=99s also analogous to the refresh token = flow, but with access tokens going in and out. I=E2=80=99ve deployed = this setup several times in different service deployments. Even though = there is a performance hit in the additional round trips (as Phil = brought up in another thread), in these cases the desire to have the = tokens hold least privilege access rights (smallest set of scopes per = service) outweighed any performance hit (which was shown to be rather = small in practice).

What I want is for the token swap draft to = define or use a mechanism that allows us to do this. I think we can do = that pretty easily by adjusting the token swap syntax and language, and = explicitly calling out the semantic processing portion (the current core = of the document) for what it is: a way for a token issuer to communicate = to a token service specific actions. At a high level, the spec would be = something like:



1. How to swap a token at an AS
  = 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in
  2. Get back a = new token in a token response
2. Communicating act as / on behalf of = semantics via a JWT assertion
  1. How to create (as an = AS/RS/client/other issuer) a JWT with act-as semantics
  2. What = to do (as an AS/RS) with a JWT with act-as semantics
  3. How to = create a JWT with on-behalf-of semeantics
  4. What to do with a = JWT with on-behalf-of-semantics
  5. How to possibly represent = these semantics with something other than a JWT



Section 2 = uses the syntax from section 1. Other applications, like the one I laid = out above, can use the syntax from section 1 as well. This works for = structured, unstructured, self-generated, cross-domain, within-domain, = and other tokens.


=E2=80=94 = Justin
_______________________________________________
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

 

<= p class=3DMsoNormal = style=3D'margin-bottom:12.0pt;background:white'> 

<= /body> ------=_NextPart_000_006B_01D067F3.505E1000-- From nobody Thu Mar 26 16:02:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A331A1ABF for ; Thu, 26 Mar 2015 16:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 wFxWwl83IZZR for ; Thu, 26 Mar 2015 16:02:27 -0700 (PDT) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E685C1A1B56 for ; Thu, 26 Mar 2015 16:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427410945; bh=J0v+cwFjaZJZH2yzoWWSU6Xvu56zsWemZcjAYEKNfXQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qdVH2v5/6MvUyoIjptazWvFfDaNV+6vVW+i1zD6CNx5Az6NM5Tx65PPeHjVJ0fwZQL/P/4jtBDACTXQzxJ+9moUeQFENfDN1LtBW4lnzjiGsF7+ng1du8/IhPNeKw55OJ9Xjh/pXCvUBqZ/3XBOXjw1LWdh4SnntZfxKZpXU90zfhhVMNQ5cQtpupzhl+6YfoL05X+mJzCzLdjmu3rVFbHj6n3m9If1EAzAcqwYHrmTOf2PuNHT8MuQbJRUkoKZem2UraTU+HJjAwkatiAfDrTn3dDOHd+y+IgYARQK1AbiDGGMJ2Crgi3Om4sIjTrwLe17qJSAmC9i84a98P9EVcA== Received: from [98.139.215.141] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 23:02:25 -0000 Received: from [98.139.212.240] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 23:02:24 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 23:02:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 976164.29273.bm@omp1049.mail.bf1.yahoo.com X-YMail-OSG: j6W8KT4VM1nSoVELAJImLAAc7SW4e8zJysKn95OFRlfhBS4_mwrR0yriqNZpHJd TfAsSMAjPYH.L6dMYeBzFXs9rkMbyoEkH1jN0exyOfh7hkPxGvLvZEJhQ7xmtuy5DmRgPB9FOMMg jgkB44BXJHfQm8EZ7QoQYZw_B7P8antSkSa2tizc16Db4IuM2yynLXm9pvmFESN7S3gFml5hbdFM 0Lae4rUkxjjkGCGpW6vy.jQ4IZ0mWGm8dXrxHJwVa924UrZz75wqp3gVDRrh0A6vs3u0_GJG5iHJ s1Mi4.D3o_sIASeSeFeZek7a31WuGZ9wVcew_oNFaBh4VA.SoQok3OcD2xXzVOmK3g0O7yZNChWX MCvZyWwoCvlkz9p1sMys4sUpyb7viV7Z6GLWbLDFOqoh6OEVFPc1L50tIWo2yn_wAogRBPY13ulH ffSr2_HG0v5MHzknYnKor05UK7q5gyLxJBvqeN9gNAJxI5d6E55m2OqTPGwglnNs.YGTLiGHECv5 qYAv5S1RaPiWC49.Pinhfmnh0uU4pQIh.zjV8bCj4RtIX Received: by 76.13.27.54; Thu, 26 Mar 2015 23:02:24 +0000 Date: Thu, 26 Mar 2015 23:02:23 +0000 (UTC) From: Bill Mills To: "Donald F. Coffin" , 'Phil Hunt' Message-ID: <1304253811.3088034.1427410943785.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <006a01d06814$d74c7090$85e551b0$@reminetworks.com> References: <006a01d06814$d74c7090$85e551b0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3088033_416792153.1427410943741" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:02:31 -0000 ------=_Part_3088033_416792153.1427410943741 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AS already has the problem of checking requested scopes, this doesn't chang= e that. In fact an AS could issue a new "refresh token" in return for the presented= one (which is the user/app AT) that's limited to be used by the RS as a cl= ient. If one of the things we want is the ability to have the AS return N access = tokens, one for each scope allowing the RS to make a single round trip requ= est to the AS for all of the more limited scope tokens, then a new grant ty= pe is in fact needed. =20 On Thursday, March 26, 2015 3:33 PM, Donald F. Coffin wrote: =20 #yiv7149031579 #yiv7149031579 -- _filtered #yiv7149031579 {font-family:Hel= vetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv7149031579 {panose-1:2= 4 5 3 5 4 6 3 2 4;} _filtered #yiv7149031579 {font-family:Calibri;panose-1= :2 15 5 2 2 2 4 3 2 4;} _filtered #yiv7149031579 {font-family:Cambria;panos= e-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv7149031579 {panose-1:3 6 8 2 4 4 6 = 7 3 4;}#yiv7149031579 #yiv7149031579 p.yiv7149031579MsoNormal, #yiv71490315= 79 li.yiv7149031579MsoNormal, #yiv7149031579 div.yiv7149031579MsoNormal {ma= rgin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579 a:link, #yi= v7149031579 span.yiv7149031579MsoHyperlink {color:blue;text-decoration:unde= rline;}#yiv7149031579 a:visited, #yiv7149031579 span.yiv7149031579MsoHyperl= inkFollowed {color:purple;text-decoration:underline;}#yiv7149031579 p.yiv71= 49031579msonormal, #yiv7149031579 li.yiv7149031579msonormal, #yiv7149031579= div.yiv7149031579msonormal {margin-right:0in;margin-left:0in;font-size:12.= 0pt;}#yiv7149031579 p.yiv7149031579msolistparagraph, #yiv7149031579 li.yiv7= 149031579msolistparagraph, #yiv7149031579 div.yiv7149031579msolistparagraph= {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579 p.yiv71= 49031579msochpdefault, #yiv7149031579 li.yiv7149031579msochpdefault, #yiv71= 49031579 div.yiv7149031579msochpdefault {margin-right:0in;margin-left:0in;f= ont-size:12.0pt;}#yiv7149031579 p.yiv7149031579msonormal1, #yiv7149031579 l= i.yiv7149031579msonormal1, #yiv7149031579 div.yiv7149031579msonormal1 {marg= in-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579 p.yiv71490315= 79msochpdefault1, #yiv7149031579 li.yiv7149031579msochpdefault1, #yiv714903= 1579 div.yiv7149031579msochpdefault1 {margin-right:0in;margin-left:0in;font= -size:12.0pt;}#yiv7149031579 span.yiv7149031579msohyperlink {}#yiv714903157= 9 span.yiv7149031579msohyperlinkfollowed {}#yiv7149031579 span.yiv714903157= 9msohyperlink1 {}#yiv7149031579 span.yiv7149031579msohyperlinkfollowed1 {}#= yiv7149031579 span.yiv7149031579emailstyle171 {}#yiv7149031579 span.yiv7149= 031579emailstyle27 {}#yiv7149031579 p.yiv7149031579msonormal2, #yiv71490315= 79 li.yiv7149031579msonormal2, #yiv7149031579 div.yiv7149031579msonormal2 {= margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579 span.yiv7= 149031579msohyperlink2 {color:blue;text-decoration:underline;}#yiv714903157= 9 span.yiv7149031579msohyperlinkfollowed2 {color:purple;text-decoration:und= erline;}#yiv7149031579 p.yiv7149031579msolistparagraph1, #yiv7149031579 li.= yiv7149031579msolistparagraph1, #yiv7149031579 div.yiv7149031579msolistpara= graph1 {margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;= margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579 p.yiv7149031579msoch= pdefault2, #yiv7149031579 li.yiv7149031579msochpdefault2, #yiv7149031579 di= v.yiv7149031579msochpdefault2 {margin-right:0in;margin-left:0in;font-size:1= 2.0pt;}#yiv7149031579 p.yiv7149031579msonormal11, #yiv7149031579 li.yiv7149= 031579msonormal11, #yiv7149031579 div.yiv7149031579msonormal11 {margin:0in;= margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579 span.yiv7149031579ms= ohyperlink11 {color:blue;text-decoration:underline;}#yiv7149031579 span.yiv= 7149031579msohyperlinkfollowed11 {color:purple;text-decoration:underline;}#= yiv7149031579 span.yiv7149031579emailstyle1711 {color:windowtext;font-weigh= t:normal;font-style:normal;text-decoration:none none;}#yiv7149031579 p.yiv7= 149031579msochpdefault11, #yiv7149031579 li.yiv7149031579msochpdefault11, #= yiv7149031579 div.yiv7149031579msochpdefault11 {margin-right:0in;margin-lef= t:0in;font-size:10.0pt;}#yiv7149031579 span.yiv7149031579emailstyle271 {col= or:windowtext;font-weight:normal;font-style:normal;text-decoration:none non= e;}#yiv7149031579 span.yiv7149031579EmailStyle39 {color:windowtext;font-wei= ght:normal;font-style:normal;text-decoration:none none;}#yiv7149031579 .yiv= 7149031579MsoChpDefault {font-size:10.0pt;} _filtered #yiv7149031579 {margi= n:1.0in 1.0in 1.0in 1.0in;}#yiv7149031579 div.yiv7149031579WordSection1 {}#= yiv7149031579 Bill, =C2=A0Thanks for the clarification. =C2=A0How do you pr= opose the AS deal with the following RFC6749 Section 6. Refreshing an Acces= s Token requirement? =C2=A0ScopeOPTIONAL.=C2=A0 The scope of the access req= uest as described by Section 3.3.=C2=A0 The requested scope MUST NOT includ= e any scope not originally granted by the resource owner, and if omitted is= treated as equal to the scope originally granted by the resource owner. = =C2=A0The authorization server MAY issue a new refresh token, in which case= the client MUST discard the old refresh token and replace it with the new = refresh token.=C2=A0 The authorization server MAY revoke the old refresh to= ken after issuing a new refresh token to the client.=C2=A0 If a new refresh= token is issued, the refresh scope MUST be identical to that of the refres= h token included by the client in the request. =C2=A0Since the RS is attemp= ting to obtain a new AT, what happens to the old AT that was submitted as a= refresh_token, should the AS issue a new refresh_token, which it is allowe= d to do as stated above?=C2=A0 Since this was really an AT, doesn=E2=80=99t= this mean the RS and issuing AS will be required to REVOKE the AT?=C2=A0 I= f the AS is not the AS that issued the original AT and there is no scope=3D= value in the request, how does it ensure the request isn=E2=80=99t asking = for more access than was granted by the granting AS? =C2=A0Best regards,Don= Donald F. CoffinFounder/CTO =C2=A0REMI Networks2335 Dunwoody Crossing Suite= EDunwoody, GA 30338-8221 =C2=A0Phone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) = 636-8571Email:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetwor= ks.com =C2=A0From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 Sent: Thursday, March 26, 2015 6:04 PM To: Bill Mills; Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case =C2=A0 =C2=A0Again, I don't= think requiring a call out to an internal token reissuer is a general solu= tion. =C2=A0That said... =C2=A0The RS calls the token endpoint treating the= AT as a refresh token in all cases and using the refresh_token grant type.= =C2=A0Desired scope is specified by the RS. =C2=A0It's not in spec if ther= e are derivative internal scopes not in the original scope list though. =C2= =A0This doesn't support internal scopes for partitioning that the AS doesn'= t know about. =C2=A0An internal AS providing chaining would need to underst= and the AT just as the RS does, and treat it as a refresh token. =C2=A0-bil= l =C2=A0On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin wrote: =C2=A0Bill,=C2=A0Can you clarify your thoughts o= n the following:=C2=A0=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 What AS endpoint does the RS call and how does it present the AT he rec= eived?=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What is the gr= ant_type value the RS use in the above endpoint request?=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What does the AS do if the AT was issu= ed by another AS (which is possible using Justin=E2=80=99s use case)?=C2=A0= Best regards,DonDonald F. CoffinFounder/CTO=C2=A0REMI Networks2335 Dunwoody= Crossing Suite EDunwoody, GA 30338-8221=C2=A0Phone:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (949) 636-8571Email:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.c= offin@reminetworks.com=C2=A0From: Bill Mills [mailto:wmills_92105@yahoo.com= ]=20 Sent: Thursday, March 26, 2015 5:13 PM To: Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case=C2=A0The RS calling back to= the AS won't be confused, the token it gets would be it's refresh token. = =C2=A0I don't see any reason why the AS can't be smart enough to know that = a token that looks like an access token it issued is usable as a refresh to= ken for limited purposes or downscoping. =C2=A0=C2=A0=C2=A0On Thursday, Mar= ch 26, 2015 1:46 PM, Donald F. Coffin wrot= e:=C2=A0-1=C2=A0Although =C2=A0Justin=E2=80=99s point might be a bit pre-ma= ture as far as a standards discussion, the more critical reason IMHO is cal= ling the AS=E2=80=99s /Token endpoint with a grant_type of =E2=80=9Crefresh= _token=E2=80=9D but providing an issued AT rather than an issued refresh_to= ken (RT) will definitely create a backwards compatibility issue for many im= plementations.=C2=A0Best regards,DonDonald F. CoffinFounder/CTO=C2=A0REMI N= etworks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221=C2=A0Phone:=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571Email:=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 donald.coffin@reminetworks.com=C2=A0From: Phil Hunt [mailto:phil.= hunt@oracle.com]=20 Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: Subject: Re: [OAUTH-WG] Token Chaining Use Case=C2=A0+1. We all have to cha= nge production code when non final specs evolve.=C2=A0=C2=A0I particularly = don't see this as a valid argument at the start of a standards discussion.= =C2=A0 Phil On Mar 26, 2015, at 15:13, Bill Mills wrote: By definition an access token is becoming a form of refresh token. =C2=A0 = =C2=A0The "because my implementation didn't do it that way" isn't convincin= g me.=C2=A0=C2=A0On Thursday, March 26, 2015 12:44 PM, Justin Richer wrote:=C2=A0Because many implementations (including mine which = does support my old token chaining draft) treat access tokens and refresh t= okens separately in terms of data store and structure. Additionally, the re= fresh token is tied to the client and presented by the client. But in this = case it's someone downstream, an RS, presenting the token. So unlike a refr= esh token being presented by the one it was issued to, this token is being = presented by someone it was presented to.=C2=A0=C2=A0The feeling is close, = but not quite the same in either development or assumptions.=C2=A0-- Justin= =C2=A0/ Sent from my phone / -------- Original message -------- From: Bill Mills =20 Date: 03/26/2015 2:24 PM (GMT-06:00)=20 To: Justin Richer , "" =20 Subject: Re: [OAUTH-WG] Token Chaining Use Case So why can't the access tok= ne simply be re-used as a refresh token? =C2=A0Why would it need a new gran= t type at all?=C2=A0=C2=A0=C2=A0On Thursday, March 26, 2015 11:31 AM, Justi= n Richer wrote:=C2=A0As requested after last night=E2=80= =99s informal meeting, here is the token chaining use case that I want to s= ee represented in the token swap draft. [ Client ]=C2=A0 ->=C2=A0 [ A ] -> [ B ] -> [ C ] An OAuth client gets an access token AT1, just like it always would, with s= copes [A, B, C] in order to call service A, which requires all three scopes= . Service A (an RS) accepts this token since it has its scope, and then nee= ds to call service B in turn, which requires scopes [B, C]. It could just r= e-send the token it got in, AT1, but that would give the downstream RS the = ability to call services with scope [ A ] and it should not be allowed to d= o that. To limit exposure, service A calls a token swap at the AS to create= AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting= a downscoped token based on AT1. Service A then acts as an OAuth client to= call service B, now acting as an RS to service A=E2=80=99s client, and can= fulfill the request. And it=E2=80=99s turtles all the way down: Service B = can also call service C, and now B acts as a client, requesting AT3 with sc= ope [ C ] based on AT2, and sending AT3 to service C. This prevents C from = being able to call B or A, both of which would have been available if AT1 h= ad been passed around. Note that service A or the Client can also request a= downscoped token with [ C ] to call service C directly as well, and C does= n=E2=80=99t have to care how it got there. In other words, it lets the client software be very, very dumb. It doesn=E2= =80=99t have to do any special processing, doesn=E2=80=99t have to know wha= t=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a to= ken, I get another token based on this to call someone else=E2=80=9D. It=E2= =80=99s also analogous to the refresh token flow, but with access tokens go= ing in and out. I=E2=80=99ve deployed this setup several times in different= service deployments. Even though there is a performance hit in the additio= nal round trips (as Phil brought up in another thread), in these cases the = desire to have the tokens hold least privilege access rights (smallest set = of scopes per service) outweighed any performance hit (which was shown to b= e rather small in practice). What I want is for the token swap draft to define or use a mechanism that a= llows us to do this. I think we can do that pretty easily by adjusting the = token swap syntax and language, and explicitly calling out the semantic pro= cessing portion (the current core of the document) for what it is: a way fo= r a token issuer to communicate to a token service specific actions. At a h= igh level, the spec would be something like: 1. How to swap a token at an AS =C2=A0 1. Send a request to the token endpoint with a new grant type, and a= token (of any type/format/flavor) on the way in =C2=A0 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion =C2=A0 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as= semantics =C2=A0 2. What to do (as an AS/RS) with a JWT with act-as semantics =C2=A0 3. How to create a JWT with on-behalf-of semeantics =C2=A0 4. What to do with a JWT with on-behalf-of-semantics =C2=A0 5. How to possibly represent these semantics with something other th= an a JWT Section 2 uses the syntax from section 1. Other applications, like the one = I laid out above, can use the syntax from section 1 as well. This works for= structured, unstructured, self-generated, cross-domain, within-domain, and= other tokens. =E2=80=94 Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth=C2=A0 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 =C2=A0 ------=_Part_3088033_416792153.1427410943741 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AS already has the problem of checking= requested scopes, this doesn't change that.
<= span>
In fact an AS could issue a new "ref= resh token" in return for the presented one (which is the user/app AT) that= 's limited to be used by the RS as a client.

If one of the t= hings we want is the ability to have the AS return N access tokens, one for= each scope allowing the RS to make a single round trip request to the AS f= or all of the more limited scope tokens, then a new grant type is in fact n= eeded.





On Thursday, March 26, 2015= 3:33 PM, Donald F. Coffin <donald.coffin@reminetworks.com> wrote:


Bill,
 
Thanks for the clarification= .
 = ;
How do= you propose the AS deal with the following RFC6749 Section 6. Refreshing a= n Access Token requirement?
 
Scope
OPTIONAL.  The scope of the access request as described by Section 3= .3.  The requested scope MUST NOT include any scope not originally gra= nted by the resource owner, and if omitted is treated as equal to the scope= originally granted by the resource owner.
 
The authori= zation server MAY issue a new refresh token, in which case the client MUST = discard the old refresh token and replace it with the new refresh token.&nb= sp; The authorization server MAY revoke the old refresh token after issuing= a new refresh token to the client.  If a new refresh token is issued,= the refresh scope MUST be identical to that of the refresh token included = by the client in the request.
 
Since the RS is attempti= ng to obtain a new AT, what happens to the old AT that was submitted as a r= efresh_token, should the AS issue a new refresh_token, which it is allowed = to do as stated above?  Since this was really an AT, doesn=E2=80=99t t= his mean the RS and issuing AS will be required to REVOKE the AT?  If = the AS is not the AS that issued the original AT and there is no scope=3D v= alue in the request, how does it ensure the request isn=E2=80=99t asking fo= r more access than was granted by the granting AS?
 
Best regards,
Do= n
Donald= F. Coffin
Founder/CTO
 
REMI Networks
2335 Dunwoody Crossing Suite E
Dunwoody, GA 30338-8221
 
Phone:   = ;   (949) 636-8571
Email:       donald.coffin@reminetworks.com
<= /div>
 <= /div>
From: Bill Mil= ls [mailto:wmills_92105@yahoo.com]
Sent: Thursday= , March 26, 2015 6:04 PM
To: Bill Mills; Donald F.= Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case
 
&nb= sp;
Again, I don't think requiring a ca= ll out to an internal token reissuer is a general solution.  That said= ...
 
The RS calls = the token endpoint treating the AT as a refresh token in all cases and usin= g the refresh_token grant type.  Desired scope is specified by the RS.=  It's not in spec if there are derivative internal scopes not in the = original scope list though.  This doesn't support internal scopes for = partitioning that the AS doesn't know about.
&nbs= p;
An internal AS providing chaining would need to= understand the AT just as the RS does, and treat it as a refresh token.
<= div id=3D"yiv7149031579yui_3_16_0_1_1427343581392_263091">
 
-bill
&= nbsp;
On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin <donald.coffin@r= eminetworks.com> wrote:
 
= Bill,
 
Can you clarify your though= ts on the following:
 
=C2=B7    &= nbsp;    What AS endpoint does the RS ca= ll and how does it present the AT he received?
=C2=B7      &= nbsp;  What is the grant_type value the RS use in = the above endpoint request?
=C2=B7&n= bsp;        What doe= s the AS do if the AT was issued by another AS (which is possible using Jus= tin=E2=80=99s use case)?
 
=
Best regards,
Don
Donal= d F. Coffin
Founder/CTO
 
REMI Networks
=
2335 Dunwoody Crossing Suite E
Dunwoody, GA 30338-8221
 <= /div>
Phone:      (949) 636-8571=
 
From: Bill Mills [mailto:wmills_92105@yahoo.com] <= br clear=3D"none">Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case
 
The RS calling back to the AS wo= n't be confused, the token it gets would be it's refresh token.  I don= 't see any reason why the AS can't be smart enough to know that a token tha= t looks like an access token it issued is usable as a refresh token for lim= ited purposes or downscoping.  
 
 
<= div>
= On Thursday, March 26, 2015 1:46 PM, Dona= ld F. Coffin <donald.coffin@reminetworks.com> wrote:
 
-1
 
Although  Justin=E2=80=99s point mig= ht be a bit pre-mature as far as a standards discussion, the more critical = reason IMHO is calling the AS=E2=80=99s /Token endpoint with a grant_type o= f =E2=80=9Crefresh_token=E2=80=9D but providing an issued AT rather than an= issued refresh_token (RT) will definitely create a backwards compatibility= issue for many implementations.
=  
Best regards,<= /div>
Don
Donald F. Coffin
Founder/CTO
<= div>
 
REMI Networks<= /span>
2335 Dunwoody Crossing Suite E
Dunwoody, GA 30338-8221
 
Phone:      (949) 636-8571
 
From: Phil Hunt [mailto:phil.hunt@oracle.c= om]
Sent: Thursday, March 26, 2015 4:22 PMTo: Bill Mills
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Chaining Use Case
 
+1. We all have to change product= ion code when non final specs evolve. 
<= div>
 
<= div class=3D"yiv7149031579MsoNormal" style=3D"background:white;">I particularly don't see this as a valid argument at the start of a = standards discussion. 

Phil

On Mar 26, 2015,= at 15:13, Bill Mills <wmills_92105@yahoo.com> wrote:
By definition an access token is becoming a form of refresh= token.    The "because my implementation didn't do it that way" = isn't convincing me.
=
 
 
On Thursday, March 26, 2015 12:44 PM, Justin Richer = <jricher@mit.edu> wr= ote:
 
=
Because many i= mplementations (including mine which does support my old token chaining dra= ft) treat access tokens and refresh tokens separately in terms of data stor= e and structure. Additionally, the refresh token is tied to the client and = presented by the client. But in this case it's someone downstream, an RS, p= resenting the token. So unlike a refresh token being presented by the one i= t was issued to, this token is being presented by someone it was presented = to. 
 
The feeling is close, but n= ot quite the same in either development or assumptions.
<= /div>
 
-- Justin
 <= /div>
/ Sent from m= y phone /


-------- Original message --------
From: Bi= ll Mills <wmi= lls_92105@yahoo.com>
Date: 03/26/2015 2:24 PM (GM= T-06:00)
To: Justin Richer <jricher@MIT.EDU>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH= -WG] Token Chaining Use Case
So why can't the access tokne simply be= re-used as a refresh token?  Why would it need a new grant type at al= l?
=  
 
&n= bsp;
<= div>
On Thursday, March 26, 2015 11:31 AM= , Justin Richer <jricher@MI= T.EDU> wrote:
=
 
=
As requested after last night=E2=80=99s informal meeting,= here is the token chaining use case that I want to see represented in the = token swap draft.


[= Client ]  ->  [ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just like it = always would, with scopes [A, B, C] in order to call service A, which requi= res all three scopes. Service A (an RS) accepts this token since it has its= scope, and then needs to call service B in turn, which requires scopes [B,= C]. It could just re-send the token it got in, AT1, but that would give th= e downstream RS the ability to call services with scope [ A ] and it should= not be allowed to do that. To limit exposure, service A calls a token swap= at the AS to create AT2 with scopes [ B, C ], effectively acting as an OAu= th client requesting a downscoped token based on AT1. Service A then acts a= s an OAuth client to call service B, now acting as an RS to service A=E2=80= =99s client, and can fulfill the request. And it=E2=80=99s turtles all the = way down: Service B can also call service C, and now B acts as a client, re= questing AT3 with scope [ C ] based on AT2, and sending AT3 to service C. T= his prevents C from being able to call B or A, both of which would have bee= n available if AT1 had been passed around. Note that service A or the Clien= t can also request a downscoped token with [ C ] to call service C directly= as well, and C doesn=E2=80=99t have to care how it got there.


In other words, it lets the cli= ent software be very, very dumb. It doesn=E2=80=99t have to do any special = processing, doesn=E2=80=99t have to know what=E2=80=99s in the token, it ju= st follows the recipe of =E2=80=9CI got a token, I get another token based = on this to call someone else=E2=80=9D. It=E2=80=99s also analogous to the r= efresh token flow, but with access tokens going in and out. I=E2=80=99ve de= ployed this setup several times in different service deployments. Even thou= gh there is a performance hit in the additional round trips (as Phil brough= t up in another thread), in these cases the desire to have the tokens hold = least privilege access rights (smallest set of scopes per service) outweigh= ed any performance hit (which was shown to be rather small in practice).
What I want is for the token swap draft = to define or use a mechanism that allows us to do this. I think we can do t= hat pretty easily by adjusting the token swap syntax and language, and expl= icitly calling out the semantic processing portion (the current core of the= document) for what it is: a way for a token issuer to communicate to a tok= en service specific actions. At a high level, the spec would be something l= ike:



1. How to swap a token at an AS
  1. Send a req= uest to the token endpoint with a new grant type, and a token (of any type/= format/flavor) on the way in
  2. Get back a new tok= en in a token response
2. Communicating act as / on behal= f of semantics via a JWT assertion
  1. How to creat= e (as an AS/RS/client/other issuer) a JWT with act-as semantics
  2. What to do (as an AS/RS) with a JWT with act-as semantics<= br clear=3D"none">  3. How to create a JWT with on-behalf-of semeantic= s
  4. What to do with a JWT with on-behalf-of-seman= tics
  5. How to possibly represent these semantics = with something other than a JWT



Section 2 uses the syntax from section 1. O= ther applications, like the one I laid out above, can use the syntax from s= ection 1 as well. This works for structured, unstructured, self-generated, = cross-domain, within-domain, and other tokens.


=E2=80=94 Justin
___________= ____________________________________
OAuth mailing listOAuth@ietf.org<= /a>
https://www.ietf.org/m= ailman/listinfo/oauth
<= /div>
&n= bsp;
_______________________________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth
 
 
=


<= /div>
------=_Part_3088033_416792153.1427410943741-- From nobody Thu Mar 26 16:26:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A791A1ADA; Thu, 26 Mar 2015 16:26: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, FREEMAIL_FROM=0.001] autolearn=ham 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 QHxKw_q3iVJf; Thu, 26 Mar 2015 16:26:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6211A0126; Thu, 26 Mar 2015 16:26:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Hannes Tschofenig" To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326232640.16758.13479.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 16:26:40 -0700 Archived-At: Cc: oauth-chairs@tools.ietf.org, draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, iesg-secretary@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-spop-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:26:49 -0000 Hannes Tschofenig has requested publication of draft-ietf-oauth-spop-10 as Proposed Standard on behalf of the OAUTH working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ From nobody Fri Mar 27 16:23:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86611A017D; Fri, 27 Mar 2015 16:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 qVYhbwOB12bT; Fri, 27 Mar 2015 16:23:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C882E1A0181; Fri, 27 Mar 2015 16:23:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150327232343.29335.55288.idtracker@ietfa.amsl.com> Date: Fri, 27 Mar 2015 16:23:43 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 23:23:45 -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 Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-07.txt Pages : 16 Date : 2015-03-27 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-introspection-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 27 16:28:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C411A017F for ; Fri, 27 Mar 2015 16:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MqEzgn3ZrqZx for ; Fri, 27 Mar 2015 16:28:21 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D3C1A004E for ; Fri, 27 Mar 2015 16:28:20 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-74-5515e793e7d9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 64.AC.03359.397E5155; Fri, 27 Mar 2015 19:28:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2RNSJ2A006747 for ; Fri, 27 Mar 2015 19:28:19 -0400 Received: from [172.16.34.209] ([199.227.111.27]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2RNSH8u021846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 27 Mar 2015 19:28:19 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_AC0E0090-784D-4A1D-8751-DD4D61797D74"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <20150327232343.29335.55288.idtracker@ietfa.amsl.com> Date: Fri, 27 Mar 2015 18:28:16 -0500 Message-Id: References: <20150327232343.29335.55288.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixCmqrDvluWioQYLFybev2BwYPZYs+ckU wBjFZZOSmpNZllqkb5fAlXHl11rmgrtSFR/+cTQwLhHrYuTkkBAwkbg75R47hC0mceHeerYu Ri4OIYHFTBLvJu1jgnCOMUr82rWIEcI5zCSx+tsNMIdZYAqjxLN3n8H6eQUMJOae+sIEYgsL eEqc3/OCFWKulETT62OMIDabgKrE9DUtYDWcAk4Sjza3gNWwAMW/XJ3CCDHHSuLmhyVsILaQ gKPEs463zCC2iIC6xJrzP4F6OYBmykv0bEqfwCgwC9kZs5CcAWIzC2hLLFv4mhnC1pTY372c BcKWl9j+dg5U3FJi8cwbUHFbiVt9C6B67SQeTVvEuoCRYxWjbEpulW5uYmZOcWqybnFyYl5e apGuoV5uZoleakrpJkZwLEjy7GB8c1DpEKMAB6MSD2/APpFQIdbEsuLK3EOMkhxMSqK8kTdF Q4X4kvJTKjMSizPii0pzUosPMaoA7Xq0YfUFRimWvPy8VCUR3g1Tgep4UxIrq1KL8mHKpDlY lMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwGj4DahQsSk1PrUjLzClBSDNxcB5ilODgARru B1LDW1yQmFucmQ6RP8WoKCXOawuSEABJZJTmwfXCUtgrRnGgt4R5dUCqeIDpD677FdBgJqDB hh0iIINLEhFSUg2MXZztYhJn/JaWTQz3YNtsUxuz9aLaLWNmiYKpr+xvRZ7dX+TwtaD78s8l 066dOuRx0qBRILH98Dzxq4wLSsL2Fq+v1L+f3rHAbaH1A/HrchsZbE/7qjMq3WTW2vlq+0cf Ce1p/KoXbWu3t/+eVryMeaVqhdbs6QsE3I97bojZ2CjFLHh4LmeXEktxRqKhFnNRcSIAAQpx bjwDAAA= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 23:28:23 -0000 --Apple-Mail=_AC0E0090-784D-4A1D-8751-DD4D61797D74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This version creates the OAuth Token Introspection Response registry as = discussed at the face-to-face meeting this past Monday. This is a new, = separate registry from the JWT registry, and it wholesale imports the = claims in the JWT registry as response elements. There are instructions = in the registry=E2=80=99s template and description about manually = coordinating with the contents of the JWT registry, which will = ultimately be the responsibility of the expert reviewers. Please check the diffs and the final version to make sure that this = makes sense, and I=E2=80=99d like to hear feedback from the wider = working group to confirm that this is the direction we want to take vis = a vis the response parameters. =E2=80=94 Justin > On Mar 27, 2015, at 6:23 PM, internet-drafts@ietf.org wrote: >=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 Working = Group of the IETF. >=20 > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-07.txt > Pages : 16 > Date : 2015-03-27 >=20 > Abstract: > This specification defines a method for a protected resource to = query > an OAuth 2.0 authorization server to determine the active state of = an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information = about > the authorization context of the token from the authorization server > to the protected resource. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-07 >=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=_AC0E0090-784D-4A1D-8751-DD4D61797D74 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVFeeRAAoJEDPAngkbd+w9YicH/Av42v2N4X4IT1DozHyLzRn2 vOLUwLGcxcCO4IiJvTl2WTetnMScjFki2jX4+b/LAMFA5Ta2+W/B4ZE2y3VKYle6 P7qMZ0JYWL/nz8lPtiTY55fvzRq+8X2feS+KnB2McbKgfWpxyJ7ZLMw3CvE2Ipbx uP2jBiRkp6BnuJis22/UUye6m11o7Q+71dLisgIA+MAHacMO8yvhD1R7ST9rqni/ qEAIZgV0w8koqd13dbJRjV/8SW3QkkCLN32HbzjNLjSFqGUHRFpxCalDo82dwHQX Iy3qobdNTWzP4WPkgkVv1KuHFrAEngt3kEW3Kiw3kfu6Aj6gUBoPgxu+r8cYi7E= =zPoc -----END PGP SIGNATURE----- --Apple-Mail=_AC0E0090-784D-4A1D-8751-DD4D61797D74-- From nobody Sat Mar 28 21:32:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15121A913E for ; Sat, 28 Mar 2015 21:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 MAZPSb_pD8tC for ; Sat, 28 Mar 2015 21:32:40 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450: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 859AE1A913A for ; Sat, 28 Mar 2015 21:32:40 -0700 (PDT) Received: by wiaa2 with SMTP id a2so81702928wia.0 for ; Sat, 28 Mar 2015 21:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sPNSB2XVeBlThpbvjTk6V/it4BkMTua0BVkCQQ8kius=; b=v3/UCREz450hF4cYuMB0NPaUT5KnSUnCshaU6TteySVcrb52ZcI4bRm0vLmyJTDkci c2Vb/cam9C1XESbN7nstmVJXaR6/K3cEhe9ocZon8ErEeDV0V6828e4lVwE2cYd+1GIL 9Ph2LIM0QsOy6hCr+fbLsv9SMVncm/uKrq2DB52QXiRDwXpcZGZRWxNVTrxMRd1DjPMK VhaTmQPT0pgiRbt+AJot+ycjZFo44bGmxnly9hl4xfn4MHJjXJU0EgDtababkKDS0D7V lwwOB4msVmaV6nygCWnfz0Cz5Jg/EoOgVfSYTWxDcHiYBe534z7PPUsuxb2O9Z+QQ+8Y C71g== MIME-Version: 1.0 X-Received: by 10.194.24.103 with SMTP id t7mr49980321wjf.15.1427603559165; Sat, 28 Mar 2015 21:32:39 -0700 (PDT) Received: by 10.194.169.169 with HTTP; Sat, 28 Mar 2015 21:32:39 -0700 (PDT) Date: Sat, 28 Mar 2015 21:32:39 -0700 Message-ID: From: =?UTF-8?Q?Andr=C3=A9_DeMarre?= To: OAuth WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OAUTH-WG] JWT/JWS/JWE confusing base64url decode language X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 04:32:42 -0000 I find the following sentence confusing: https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2 Base64url decode the Encoded JOSE Header following the restriction that no line breaks, white space, or other additional characters have been used. When it says to decode following the restriction that certain characters have not been used, is this supposed to mean (A) that those characters are illegal in the encoded representation, or (B) that those characters must be discarded if encountered in the decode function? Disregarding domain knowledge and examining the prose alone, I would warily conclude A. The difference is significant, affecting the strictness of token validation. Consider a JWT with an arbitrary 0x0A line break somewhere before the first period, resulting in the following JOSE header with a line break: eyJ0eXAiOiJKV1Qi LA0KICJhbGciOiJIUzI1NiJ9 Similarly, the following header could result from a base64url encoder that retains the common "=" padding: eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0= Under interpretation A, the headers are invalid and cannot be decoded. Under interpretation B, the line break and "=" would be ignored, and the headers would be decoded successfully. How strict do we want JWT/JWS/JWE validation to be? Whichever the case, I think the paragraph quoted above should simply omit the 'restriction' comment: Base64url decode the Encoded JOSE Header. The original phrasing apparently comes from the JWS spec, and is duplicated for JWE: https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-5.2 https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40#section-5.2 If needed, further instruction on how to handle unexpected characters should be done normatively in the base64url definition (https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-2) or maybe in the JWT structure overview. Notice also that the example C# base64urldecode() function (https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-C) is lenient. So lenient in fact that it accepts BOTH the regular base64 and base64url encodings from RFC 4648. Regards, Andre DeMarre From nobody Sat Mar 28 22:22:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECE91A914E for ; Sat, 28 Mar 2015 22:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 iKrEZzK4SyrG for ; Sat, 28 Mar 2015 22:22:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E4F1A9149 for ; Sat, 28 Mar 2015 22:22:22 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.125.14; Sun, 29 Mar 2015 05:22:05 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 05:22:04 +0000 From: Mike Jones To: =?windows-1256?Q?Andr=E9_DeMarre?= , OAuth WG Thread-Topic: [OAUTH-WG] JWT/JWS/JWE confusing base64url decode language Thread-Index: AQHQadlqUVPskxCKAECiK9qKdhiY3Z0y7OG1 Date: Sun, 29 Mar 2015 05:22:03 +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: [166.170.43.196] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(46102003)(16236675004)(40100003)(2950100001)(2900100001)(66066001)(19580405001)(19580395003)(92566002)(19617315012)(102836002)(76576001)(77096005)(15975445007)(19625215002)(33656002)(74316001)(87936001)(575784001)(122556002)(86612001)(62966003)(77156002)(107886001)(54356999)(2656002)(86362001)(50986999)(99286002)(76176999)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0530FCB552 Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4423A24370CC3A71E01FD0CF5F60BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 05:22:03.6297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] JWT/JWS/JWE confusing base64url decode language X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 05:22:24 -0000 --_000_BY2PR03MB4423A24370CC3A71E01FD0CF5F60BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable (A) ________________________________ From: Andr=E9 DeMarre Sent: =FD3/=FD28/=FD2015 9:32 PM To: OAuth WG Subject: [OAUTH-WG] JWT/JWS/JWE confusing base64url decode language I find the following sentence confusing: https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2 Base64url decode the Encoded JOSE Header following the restriction that no line breaks, white space, or other additional characters have been used. When it says to decode following the restriction that certain characters have not been used, is this supposed to mean (A) that those characters are illegal in the encoded representation, or (B) that those characters must be discarded if encountered in the decode function? Disregarding domain knowledge and examining the prose alone, I would warily conclude A. The difference is significant, affecting the strictness of token validation. Consider a JWT with an arbitrary 0x0A line break somewhere before the first period, resulting in the following JOSE header with a line break: eyJ0eXAiOiJKV1Qi LA0KICJhbGciOiJIUzI1NiJ9 Similarly, the following header could result from a base64url encoder that retains the common "=3D" padding: eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0=3D Under interpretation A, the headers are invalid and cannot be decoded. Under interpretation B, the line break and "=3D" would be ignored, and the headers would be decoded successfully. How strict do we want JWT/JWS/JWE validation to be? Whichever the case, I think the paragraph quoted above should simply omit the 'restriction' comment: Base64url decode the Encoded JOSE Header. The original phrasing apparently comes from the JWS spec, and is duplicated for JWE: https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-5= .2 https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40#section-= 5.2 If needed, further instruction on how to handle unexpected characters should be done normatively in the base64url definition (https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-= 2) or maybe in the JWT structure overview. Notice also that the example C# base64urldecode() function (https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix= -C) is lenient. So lenient in fact that it accepts BOTH the regular base64 and base64url encodings from RFC 4648. Regards, Andre DeMarre _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BY2PR03MB4423A24370CC3A71E01FD0CF5F60BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
(A)
From: Andr=E9 DeMarre
Sent: =FD3/= =FD28/=FD2015 9:32 PM
To: OAuth WG
Subject: [OAUT= H-WG] JWT/JWS/JWE confusing base64url decode language

I find the following sentence confusing:

https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#= section-7.2
        Base64url decode the Encoded JOS= E Header following the
        restriction that no line breaks,= white space, or other
        additional characters have been = used.

When it says to decode following the restriction that certain
characters have not been used, is this supposed to mean (A) that those
characters are illegal in the encoded representation, or (B) that
those characters must be discarded if encountered in the decode
function?

Disregarding domain knowledge and examining the prose alone, I would
warily conclude A.

The difference is significant, affecting the strictness of token
validation. Consider a JWT with an arbitrary 0x0A line break somewhere
before the first period, resulting in the following JOSE header with a
line break:

eyJ0eXAiOiJKV1Qi
LA0KICJhbGciOiJIUzI1NiJ9

Similarly, the following header could result from a base64url encoder
that retains the common "=3D" padding:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0=3D

Under interpretation A, the headers are invalid and cannot be decoded.
Under interpretation B, the line break and "=3D" would be ignored= , and
the headers would be decoded successfully.

How strict do we want JWT/JWS/JWE validation to be?

Whichever the case, I think the paragraph quoted above should simply
omit the 'restriction' comment:
        Base64url decode the Encoded JOS= E Header.

The original phrasing apparently comes from the JWS spec, and is
duplicated for JWE:
https://tools.ietf.org/html/draft-ietf-jose-json-web-signatu= re-41#section-5.2
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryp= tion-40#section-5.2

If needed, further instruction on how to handle unexpected characters
should be done normatively in the base64url definition
(https://tools.ietf.org/html/draft-ietf-jose-json-web-signatur= e-41#section-2)
or maybe in the JWT structure overview.

Notice also that the example C# base64urldecode() function
(https://tools.ietf.org/html/draft-ietf-jose-json-web-signatu= re-41#appendix-C)
is lenient. So lenient in fact that it accepts BOTH the regular base64
and base64url encodings from RFC 4648.


Regards,
Andre DeMarre

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth
 --_000_BY2PR03MB4423A24370CC3A71E01FD0CF5F60BY2PR03MB442namprd_-- From nobody Mon Mar 30 07:03:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFE21ACEED for ; Mon, 30 Mar 2015 07:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 titMalHsTjN4 for ; Mon, 30 Mar 2015 07:03:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A451ACE22 for ; Mon, 30 Mar 2015 07:03:34 -0700 (PDT) Received: from [192.168.131.145] ([80.92.114.249]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MFdDB-1Yhow52tE5-00EavX for ; Mon, 30 Mar 2015 16:03:32 +0200 Message-ID: <551957B3.6010201@gmx.net> Date: Mon, 30 Mar 2015 16:03:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Kmn1EfDjnGpV7FdC103DAmRCSBA0PuwRe" X-Provags-ID: V03:K0:ubMDqqX9uQl7rV8+BeNWzzS1epWHshyYSPRT776nUMYgy6ijpsq VnVjyifUCFLLUeer7iU30rdI7pgPmz2R9k+2u/r25L4BmxuW5qqNHRLVMOcFlc0u1TvrtTr SOJBSu2eImWbuWovcvkw8ShbYL9yJkmpPSD9UE6nDYPhc+xF1//QGjvjtmY6Q5yISsWwl/U o9bSgfuNSDb1G2jqxU3YA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-spop-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 14:03:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kmn1EfDjnGpV7FdC103DAmRCSBA0PuwRe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Nat and I went through the latest version of the Proof Key for Code Exchange (PKCE) draft and I completed the shepherd writeup. You can find the writeup here: http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/shepherdwriteup/ Ciao Hannes --Kmn1EfDjnGpV7FdC103DAmRCSBA0PuwRe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVGVe0AAoJEGhJURNOOiAtWKAH/RIra3Gi/p/Wos6knaNANdX2 bQHCaVndwjYw1Ld6+4DE3n7+QjVMimVKVmz6ne9LO9cIXDAgy2XMz4qlT7435IpN xTdOPIIz/3dptS6EqvPLIjkhcs2E3H+kxcxHwW++waodkKp55RIUKnR5E7jVvOTb ZdyUglIRoZrvRPSAULorfkwEg4EkcgSNCPvc/LScdGAQrMNeXIQM/LviNpoOXkWJ dVnvofFFq3tzJ2iRkM4NcEeTLgQWmX6HkxEGIfx+lHm6o5fsMpxScxk23YgzBTt0 nbRQ/P47mQorMKAB20yWceOvO4+GZdJaUkplf/8D/F0vdAJPkBQtrUZA0+RqyL0= =sk7A -----END PGP SIGNATURE----- --Kmn1EfDjnGpV7FdC103DAmRCSBA0PuwRe-- From nobody Tue Mar 31 02:08:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60641A0210 for ; Tue, 31 Mar 2015 02:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1b-iVf3IMO1c for ; Tue, 31 Mar 2015 02:08:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA20E1A0108 for ; Tue, 31 Mar 2015 02:08:51 -0700 (PDT) Received: from [192.168.131.145] ([80.92.114.249]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MKu9E-1YcsAC0f5c-00051L for ; Tue, 31 Mar 2015 11:08:48 +0200 Message-ID: <551A641F.8050909@gmx.net> Date: Tue, 31 Mar 2015 11:08:47 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ms9JAc9iof9Xr4rGQvqIDWtHfn2EX4DLb" X-Provags-ID: V03:K0:AnMo469eHlYk0ayZ+B+Bv8QjO12MJ39MHDWU2Q/qF2rHf90S2+H 3tcySi6d58yxwZJ0JnGUI5gtFOH2txuCXtW9KEl/MSr3E3EjBAAnNY1orIifB7pD9tE1WYm BsXQkvoLLV3OsuZNXqtWUx+jXD3d2Cr3KG9kv92+auL9deaf18yBQ7lipd9YqR2fbR/m0U3 XhbErbCTdZhWjt+lvk9cA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 09:08:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ms9JAc9iof9Xr4rGQvqIDWtHfn2EX4DLb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The minutes from our OAuth f2f meeting have been uploaded to http://www.ietf.org/proceedings/92/minutes/minutes-92-oauth Thanks to Tony for taking notes. Ciao Hannes & Derek --------------------------------- OAUTH WG WG STATUS Oauth Assertion Framework =E2=80=93 RFC Editor Queue JWT - RFC Editor JWT Bearer - RFC Editor Proof Key for code exchange =E2=80=93 to IESG PoP Architecture =E2=80=93 to IESG PoP Semantics for JWT WGLC in Progress Token Introspection =E2=80=93 Shepherd write up Token Introspection =E2=80=93 Justin Made changes from WGLC most notably some specific requirements for =E2=80= =9Cactive=E2=80=9D Open Issues: Registries Main issues is trying use the JWT registry with Token Introspection, so there is a (1) proposal to extend the JWT registry or (2) to create a new registry and seed it with the JWT registry, (3) and last proposal is to create a new introspection registry-only Mike =E2=80=93 is for option2 to be aligned with how this has been done b= efore Brian =E2=80=93 2 separate registries are needed, so option 2 would work John =E2=80=93 Does not want the JWT to be a dumping ground, so separate registries needed Poll =E2=80=93 option 1 =E2=80=93 0 votes, option 2 =E2=80=93 12, option = 3 -1 POP Semantics =E2=80=93 Mike WGLC ends soon, new comments came in so need to talk about these and push a new draft out Brian =E2=80=93 Made some editorial comments, concerns over the CNF and t= he structure. Review document =E2=80=93 Justin, Nat John Bradley gave overview of Proof of Possession Proof-of-Possession Blog post from John Bradley see http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.htm= l Discussion over how to stay in step with the industry, other ietf work PoP AS to Client Key Distribution - Hannes and John Bradley Open Issues =E2=80=93 can asymmetric keys be used with more than one reso= urce server Protect Refresh Token as well as Access token ? TBD, need usecase Need to have more discussions on client held keys and server keys There needs to be a matrix of all the options that may be available (will call out the various redundancies) HTTP Message signing Tie and OAUTH token and signature to a specific HTTP request This is not binding to the TLS session There are other ways to do this, OAUTH 1.0 and AWS OAUTH Token Exchange ActAS, onBehalfOf functionality Stable drafts Need more input and more eyes on this Phil =E2=80=93 so folks are not interested in the expensive token chains = and validating Brian =E2=80=93 none of his feedback has been considered In-official meeting will be scheduled during this week. Open Redirectors Leaks information in the fragment and referrer, this applies to all protocols that use redirects Some of the mitigations Append fragments to all redirects Internal redirect Append content-security-policy Header Include Referrer meta tag So do we do something specific in OAUTH like put this into the security document Suggestion to update the OAuth Thread document to include these types of recommendations. No decision made. Destination Claim =E2=80=93 Brian A new claim for specifying the destination of the JWT, not the same as audience (who) but where is the key, A single value destination, may need to make this a multi-value Discussion needed how it is different to the audience claim. End of meeting --ms9JAc9iof9Xr4rGQvqIDWtHfn2EX4DLb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVGmQfAAoJEGhJURNOOiAtktAH/1ZOa0SFfVM6vw+nPRAyTiDW k1FopEZICzvAjyUnmrdLWeKA3QRvuPhl+begVBwjMwGo1zg+Bu8heubSQKwEZ/IY bAiu9fxI+O5JiK3buD/5kWr4O7CMqMYtPBhAhB27bL6NF0KObpO7jEbuIb20QEO7 n/7yKh+RXiohU2btOoBWjHkV01SCgJ8UkuxhfbvSjv4rtg+kipXMnsqUke0jDmep 8xZAJPJhQTgAQDIlZmkRTE9kazjuDV4CS+lEQZ02MEkbv478lerhH/ZHceoig94d xrQ7JnHD3SnYudjKskW+lPiRmshXNjfx3AcfWx9fnLqE6oXeCF90vCmiENZJs1s= =KMcy -----END PGP SIGNATURE----- --ms9JAc9iof9Xr4rGQvqIDWtHfn2EX4DLb-- From nobody Tue Mar 31 02:30:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9143C1A1B60 for ; Tue, 31 Mar 2015 02:30:49 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 A8016vRZMBgo for ; Tue, 31 Mar 2015 02:30:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961BC1A1B5E for ; Tue, 31 Mar 2015 02:30:47 -0700 (PDT) Received: from [192.168.131.145] ([80.92.114.249]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MLA45-1Yd9UL3eMb-000Khu; Tue, 31 Mar 2015 11:30:45 +0200 Message-ID: <551A6943.70905@gmx.net> Date: Tue, 31 Mar 2015 11:30:43 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Richer , "" References: <20150327232343.29335.55288.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QoRW1u92F1GQ9sl2GmgemN2SL85vsxLxP" X-Provags-ID: V03:K0:Bc/s/rhfBItT8qvSTBaZy/5HMX7MQwsVoUq4LsyL9vdnEtm1iPK v5WDK1xTb5P3We7mIM7S9K90paxPOf1BJukXjZv72OEmd6WeyXkdtPUpd4v7xDJohVPVk7C FApfd8fHXj9vW7jav4xsA554iuX+IaVwWgSPxIY/nHjrfgfEYuzEtzetPFY89AQ2cGm0EY3 FsxV6X+ZPtw630qa434Tw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 09:30:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QoRW1u92F1GQ9sl2GmgemN2SL85vsxLxP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Justin, thank you for quickly updating the document to give the working group a chance to review the proposed text for the open issue regarding the registry. We should give the group a couple of days to decide whether they like the change. I looked at the text and it is fine with me. I was, however, wondering whether the expert reviewers should be given some guidance. For example, I could imagine that it would be helpful to check a new claim against the JWT registry. What we would like to avoid is to have claims in the introspection registry that have the same name but a different semantic compared to those in the JWT registry. That could lead to a lot of confusion. Ciao Hannes On 03/28/2015 12:28 AM, Justin Richer wrote: > This version creates the OAuth Token Introspection Response registry as= discussed at the face-to-face meeting this past Monday. This is a new, s= eparate registry from the JWT registry, and it wholesale imports the clai= ms in the JWT registry as response elements. There are instructions in th= e registry=92s template and description about manually coordinating with = the contents of the JWT registry, which will ultimately be the responsib= ility of the expert reviewers. >=20 > Please check the diffs and the final version to make sure that this mak= es sense, and I=92d like to hear feedback from the wider working group to= confirm that this is the direction we want to take vis a vis the respons= e parameters. >=20 > =97 Justin >=20 >> On Mar 27, 2015, at 6:23 PM, internet-drafts@ietf.org wrote: >> >> >> 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 Working Gr= oup of the IETF. >> >> Title : OAuth 2.0 Token Introspection >> Author : Justin Richer >> Filename : draft-ietf-oauth-introspection-07.txt >> Pages : 16 >> Date : 2015-03-27 >> >> Abstract: >> This specification defines a method for a protected resource to quer= y >> an OAuth 2.0 authorization server to determine the active state of a= n >> OAuth 2.0 token and to determine meta-information about this token. >> OAuth 2.0 deployments can use this method to convey information abou= t >> the authorization context of the token from the authorization server= >> to the protected resource. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-introspection-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-07 >> >> >> 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 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --QoRW1u92F1GQ9sl2GmgemN2SL85vsxLxP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVGmlDAAoJEGhJURNOOiAtE7UH/Amg1XPWM8RgA4zrNejsv6sx xeuqTVeS5S4Uhyo0Xrtp+VRLE9OHAbw91VjRo+dfr1Y9Z+jmV69OLp1ovOmuXARB +ESFTnV+eLWPO9RPjU5uwQwC5dFynkgS+DIUyE8lrbWdX9injMwrp55ffZcKpinO bmUvD1Yy7MMOxaJdHdBIjMvGTD/ILRiIb3bq5EREUb3xKLKZhxx+/slGaEkO1cK3 KaXyj/c+6pOSN4whvRdU6a2FOwRTP4HL1xjN6R3XL8wwByOHN/5lChXk+1umGH4s pzG2KzwBwpqOxc8K+xlQ9xBCA6sexpOcQy7qM0cyHB+VWWxdB0m9v6Ywv7DF+4s= =XV61 -----END PGP SIGNATURE----- --QoRW1u92F1GQ9sl2GmgemN2SL85vsxLxP-- From nobody Tue Mar 31 06:10:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833291ACD1C for ; Tue, 31 Mar 2015 06:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ta6JeVncsQZG for ; Tue, 31 Mar 2015 06:10:38 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE3B1ACD19 for ; Tue, 31 Mar 2015 06:10:38 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-95-551a9ccc7fd0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 92.65.03488.CCC9A155; Tue, 31 Mar 2015 09:10:36 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2VDAZql008791; Tue, 31 Mar 2015 09:10:36 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2VDAYuB022713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 31 Mar 2015 09:10:35 -0400 Message-ID: <551A9CC6.8080301@mit.edu> Date: Tue, 31 Mar 2015 09:10:30 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , "" References: <20150327232343.29335.55288.idtracker@ietfa.amsl.com> <551A6943.70905@gmx.net> In-Reply-To: <551A6943.70905@gmx.net> Content-Type: multipart/alternative; boundary="------------010701070103090708090209" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hRV1j0zRyrUYMFyTYulO++xWpx8+4rN gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4u3UhY8H5gIpvE16wNzBOd+xi5OSQEDCR OHrzCzOELSZx4d56ti5GLg4hgcVMEgvnHGGHcDYySpx6shYqc5tJYv+VTYwgLbwCahINO36x gNgsAqoSZ3a2gcXZgOzpa1qYQGxRgSiJnj/dbBD1ghInZz4BqxcRiJeYf7IHrEZYwFPi/J4X rBALOhklFkzpYgdJcAINurrxDthQZoEwiY9n9zFPYOSfhWTWLCQpCNtW4s7c3VC2vETz1tlQ tq7Eom0r2JHFFzCyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAgObkneHYzv DiodYhTgYFTi4b1wTzJUiDWxrLgy9xCjJAeTkijv/SqpUCG+pPyUyozE4oz4otKc1OJDjBIc zEoivD8nAuV4UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4d88GahQs Sk1PrUjLzClBSDNxcIIM5wEaPhOkhre4IDG3ODMdIn+KUVFKnLcSJCEAksgozYPrhSWfV4zi QK8I8/4BqeIBJi647ldAg5mABp9eJQ4yuCQRISXVwLiqQrFSTPDzt/sGErI/uI8/X79++vn5 DG/vbDeb5Xfp3XEF77TdPdLFgnNuf1qjV/TysFfCf16dfRNZ7JPV1WMcal/lC5/N0134OjRr 2ZF1KjrGS2IKPWbdutkatvbf6b0+GrHurTeYOBbsjtyyWHNOObfIjG2eS8+IuLuI7ugSeJKS H7hV66USS3FGoqEWc1FxIgCqclvrGQMAAA== Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 13:10:41 -0000 This is a multi-part message in MIME format. --------------010701070103090708090209 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hannes, Yes, disambiguation with JWT is a very important goal here, since both are talking about token information. The document currently has this text in 3.1.1: Name: The name requested (e.g., "example"). This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted. Names that match claims registered in the JSON Web Token Claims registry established by [JWT ] SHOULD have comparable definitions and semantics. But perhaps we can push this even further. Additionally, the review list is the oauth-ext list, but perhaps it should be jwt-ext in addition or instead of oauth-ext. I'd like WG feedback on that aspect as well. -- Justin On 3/31/2015 5:30 AM, Hannes Tschofenig wrote: > Hi Justin, > > thank you for quickly updating the document to give the working group a > chance to review the proposed text for the open issue regarding the > registry. > > We should give the group a couple of days to decide whether they like > the change. > > I looked at the text and it is fine with me. I was, however, wondering > whether the expert reviewers should be given some guidance. For example, > I could imagine that it would be helpful to check a new claim against > the JWT registry. What we would like to avoid is to have claims in the > introspection registry that have the same name but a different semantic > compared to those in the JWT registry. That could lead to a lot of > confusion. > > Ciao > Hannes > > On 03/28/2015 12:28 AM, Justin Richer wrote: >> This version creates the OAuth Token Introspection Response registry as discussed at the face-to-face meeting this past Monday. This is a new, separate registry from the JWT registry, and it wholesale imports the claims in the JWT registry as response elements. There are instructions in the registry’s template and description about manually coordinating with the contents of the JWT registry, which will ultimately be the responsibility of the expert reviewers. >> >> Please check the diffs and the final version to make sure that this makes sense, and I’d like to hear feedback from the wider working group to confirm that this is the direction we want to take vis a vis the response parameters. >> >> — Justin >> >>> On Mar 27, 2015, at 6:23 PM, internet-drafts@ietf.org 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 Working Group of the IETF. >>> >>> Title : OAuth 2.0 Token Introspection >>> Author : Justin Richer >>> Filename : draft-ietf-oauth-introspection-07.txt >>> Pages : 16 >>> Date : 2015-03-27 >>> >>> Abstract: >>> This specification defines a method for a protected resource to query >>> an OAuth 2.0 authorization server to determine the active state of an >>> OAuth 2.0 token and to determine meta-information about this token. >>> OAuth 2.0 deployments can use this method to convey information about >>> the authorization context of the token from the authorization server >>> to the protected resource. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-introspection-07 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 >> --------------010701070103090708090209 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hannes,

Yes, disambiguation with JWT is a very important goal here, since both are talking about token information. The document currently has this text in 3.1.1:

   Name:
      The name requested (e.g., "example").  This name is case
      sensitive.  Names that match other registered names in a case
      insensitive manner SHOULD NOT be accepted.  Names that match
      claims registered in the JSON Web Token Claims registry
      established by [JWT] SHOULD have comparable definitions and
      semantics.

But perhaps we can push this even further. Additionally, the review list is the oauth-ext list, but perhaps it should be jwt-ext in addition or instead of oauth-ext. I'd like WG feedback on that aspect as well.

 -- Justin

On 3/31/2015 5:30 AM, Hannes Tschofenig wrote:
Hi Justin,

thank you for quickly updating the document to give the working group a
chance to review the proposed text for the open issue regarding the
registry.

We should give the group a couple of days to decide whether they like
the change.

I looked at the text and it is fine with me. I was, however, wondering
whether the expert reviewers should be given some guidance. For example,
I could imagine that it would be helpful to check a new claim against
the JWT registry. What we would like to avoid is to have claims in the
introspection registry that have the same name but a different semantic
compared to those in the JWT registry. That could lead to a lot of
confusion.

Ciao
Hannes

On 03/28/2015 12:28 AM, Justin Richer wrote:

This version creates the OAuth Token Introspection Response registry as discussed at the face-to-face meeting this past Monday. This is a new, separate registry from the JWT registry, and it wholesale imports the claims in the JWT registry as response elements. There are instructions in the registry’s template and description about manually coordinating with the  contents of the JWT registry, which will ultimately be the responsibility of the expert reviewers.

Please check the diffs and the final version to make sure that this makes sense, and I’d like to hear feedback from the wider working group to confirm that this is the direction we want to take vis a vis the response parameters.

 — Justin


On Mar 27, 2015, at 6:23 PM, internet-drafts@ietf.org 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 Working Group of the IETF.

       Title           : OAuth 2.0 Token Introspection
       Author          : Justin Richer
	Filename        : draft-ietf-oauth-introspection-07.txt
	Pages           : 16
	Date            : 2015-03-27

Abstract:
  This specification defines a method for a protected resource to query
  an OAuth 2.0 authorization server to determine the active state of an
  OAuth 2.0 token and to determine meta-information about this token.
  OAuth 2.0 deployments can use this method to convey information about
  the authorization context of the token from the authorization server
  to the protected resource.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-introspection-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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



    

    

  


--------------010701070103090708090209--