From nobody Thu Jun 1 05:32:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912ED129516 for ; Thu, 1 Jun 2017 05:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqPy-Mcv8q1k for ; Thu, 1 Jun 2017 05:32:45 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 000F312EC11 for ; Thu, 1 Jun 2017 05:32:44 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id y190so23821343vkc.1 for ; Thu, 01 Jun 2017 05:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=b4kV5fZDMH0p/n4yDm/2/2Kw28FI4VIKFuY61iLveuQ=; b=EYtC8vO4jbDGItOYUbqlLobkzANy1Ll7vEskPsJqoGQThgkap3HeDjQQOv4cYf2FrX 9HGklAqoFb5D2VTnMQVO9gZ1OESZjZzFnm+uxSRlITy8aERjBBUG629iMY378IquEeKI uJPSvqr5hrRRN3Lo+l/kObcpmWk2ct7X+riXUkYgZepdGux3QOfviLjEzzJU6A5Ru/xo Neb9yqzbPL0gDSALsamT4wu4Gh6i/UMey7taixewo5yju/NbAYe+3/Ejkyy+aYechqYm R8k1Riayjc5A483AW/2rcQJhmM5/uJs2rDVlkbwulqyoP2TQhh3sBa28taMwCuIdnWog PsJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b4kV5fZDMH0p/n4yDm/2/2Kw28FI4VIKFuY61iLveuQ=; b=WhNErAmDk/rYVdcqIRdjd5SVGP0DUz80z6scx8zjTH1iVp1dvBuKCbszbWJJGWGbcl h+fc9imxK9AR5FRVa/Od6N/BhT2sEu0VIvncthcuk5URa5Z92Xl2M83CZrPlZ6ot2auC k+Cc6/1NfboPsvqtT8tBdU34j6DORqA/0KMkXeEKNoQNW6bI9RLwRdiuf1ifAt6fARFv TFnC9KeqRzZQMLsBHGJmzVsVw1kJeOwJnNqUUhwojzBjLi9QBaBDCnl/M16uZarwZ0UB Qzjt4IVkyu1JO3I6/Wugo9c3KYJ1zuKuPFY7RLdgu3wl2FEuxjY9shWKp1UCz91EmjYz U+fg== X-Gm-Message-State: AODbwcCDOr0QbqJVMGD8YppECpXmoJzpdv4eLcAIPjZs1iogKcvJaUhE 34IHFRFmlUCeJp9juJrfYFHbOE2f05mG X-Received: by 10.31.234.130 with SMTP id i124mr615766vkh.86.1496320363827; Thu, 01 Jun 2017 05:32:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.91 with HTTP; Thu, 1 Jun 2017 05:32:43 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Thu, 1 Jun 2017 08:32:43 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c09503ec19a960550e53bf3" Archived-At: Subject: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 12:32:47 -0000 --94eb2c09503ec19a960550e53bf3 Content-Type: text/plain; charset="UTF-8" All, We are starting a WGLC on the Device Flow document: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 Please, review the document and provide feedback on any issues you see with the document. The WGCL will end in two weeks, on June 16, 2017. Regards, Rifaat and Hannes --94eb2c09503ec19a960550e53bf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We are starting a WGLC on the Devi= ce Flow document:

Please, review the document and = provide feedback on any issues you see with the document.

The WGCL will end in two weeks, on June 16, 2017.
Regards,
=C2=A0Rifaat and Hannes
--94eb2c09503ec19a960550e53bf3-- From nobody Thu Jun 1 06:08:25 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3C129BCA; Thu, 1 Jun 2017 06:08:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ekr@rtfm.com, Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149632250390.22080.2004222184792945466.idtracker@ietfa.amsl.com> Date: Thu, 01 Jun 2017 06:08:23 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 99 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 13:08:24 -0000 A new meeting session request has just been submitted by Hannes Tschofenig, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag core tls tokbind ace sipcore People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: Please avoid conflict with sec area BoFs. Please avoid the Friday. --------------------------------------------------------- From nobody Thu Jun 1 18:41:54 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA7A12949D for ; Thu, 1 Jun 2017 18:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxwDnh6MABgC for ; Thu, 1 Jun 2017 18:41:49 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 B062F12948F for ; Thu, 1 Jun 2017 18:41:49 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m47so4555409iti.1 for ; Thu, 01 Jun 2017 18:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tZ8v/OB5Mj16Vm81ZSuhklSBV/bPhbXCUO4yqseMywA=; b=dhOKEXZnETijS+i5CKoTag/Tp/+ynLT7hnBoE+P36eBMKwVWqpW6exPfycj7sQuCOr A4DbZC3ygPc3zkmtip0mOPy9/e59FPBz8e3Q4YQq2bEiUqlml243vetRdC0EqWaOfy1f /b8oTaqM+CyuyIMpVjxOrWLI8nDVUk6iLN+sxmYhY360tKv5jX0WpQ8B4kQ1zAcLnzVV 2xy8d4a3dCugTD1brbBgDolHwzHjFWpNfLCMpDTkJ2rZvCah4dEGmPvVDX1koXIRY3Og Aew3Ieg3kzPWvjM4Z2h8UchnGW1kZXBDk7uwQYsEJgWDUM2tz8g+Q4l3sqvnq70o6jBm SZ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tZ8v/OB5Mj16Vm81ZSuhklSBV/bPhbXCUO4yqseMywA=; b=If+N/h2vInQeZEk9Ieudi3FFab0O8SOetPKzoEwZHzW1frlou4Lm9LRPrf4J83fRb7 TFC+Fz1/cnFCNe6KTZdkS0Y6Y2Eet5MdEAHqxTsjV4gDPNTsftflGqah8nSlYsmvb864 WMee1U6dVTFIAu/N4WQ5CU+99JB1hlptf1fEfnQJxy5ETwlwFbt3VZNHecz3Afv0CIGG HF4QnZ8NlSakeXp4X09Zahxwtvy1Ti7Iwu18evXWRoGCd2HsIcoYfN1ZP2sGuHsOW7DN Inxfwcp/Mx9T5suZCW65Ccr+U/fgEOJMa0PwKNBOsCKRUqSlnlTF/3a5i55k/iI/Acn/ Sigw== X-Gm-Message-State: AODbwcDTo4ZCN+zVMm+gdxjiwt4Z1eDJFrQFtCvxdW46iM/mNWkleLKg i13u1gTb4crkgwGfmnQ83An593z9b4wy X-Received: by 10.36.23.22 with SMTP id 22mr2397445ith.78.1496367708782; Thu, 01 Jun 2017 18:41:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.37 with HTTP; Thu, 1 Jun 2017 18:41:28 -0700 (PDT) In-Reply-To: <1495642815.971519.987329656.342C84A9@webmail.messagingengine.com> References: <149563962282.28554.14590140614058686244.idtracker@ietfa.amsl.com> <1495642815.971519.987329656.342C84A9@webmail.messagingengine.com> From: William Denniss Date: Thu, 1 Jun 2017 18:41:28 -0700 Message-ID: To: Alexey Melnikov Cc: Brian Campbell , The IESG , draft-ietf-oauth-native-apps@ietf.org, oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="001a1143e36abc97d70550f04130" Archived-At: Subject: Re: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 01:41:52 -0000 --001a1143e36abc97d70550f04130 Content-Type: text/plain; charset="UTF-8" Thanks Alexey and Brian. In my staged copy, I've added a reference to RFC7230, which according to IANA holds the definition of the https scheme. Will be included in the next update. I also verified that our Section 2 includes "NOT RECOMMENDED" per the errata. On Wed, May 24, 2017 at 9:20 AM, Alexey Melnikov wrote: > On Wed, May 24, 2017, at 05:17 PM, Brian Campbell wrote: > > As far as I can tell, 'NOT RECOMMENDED' is fine per RFC 2119. > > > from https://www.ietf.org/rfc/rfc2119.txt > > 4. SHOULD NOT This phrase, *or the phrase "NOT RECOMMENDED"* mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > And also this errata notes that NOT RECOMMENDED should be in the first part of the abstract https://www.rfc-editor.org/errata_search.php?rfc=2119&eid=499 > > > Never mind then! > > > On Wed, May 24, 2017 at 9:27 AM, Alexey Melnikov > wrote: > > Alexey Melnikov has entered the following ballot position for > draft-ietf-oauth-native-apps-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A couple of nits: > > 8.2. OAuth Implicit Grant Authorization Flow > > The OAuth 2.0 implicit grant authorization flow as defined in > Section 4.2 of OAuth 2.0 [RFC6749] generally works with the practice > of performing the authorization request in the browser, and > receiving > the authorization response via URI-based inter-app communication. > However, as the Implicit Flow cannot be protected by PKCE (which is > a > required in Section 8.1), the use of the Implicit Flow with native > apps is NOT RECOMMENDED. > > NOT RECOMMENDED is not actually a construct allowed by RFC 2119, I think > you should reword it using "SHOULD NOT". > > It would be good to add RFC reference for HTTPS URIs. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a1143e36abc97d70550f04130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Alexey and Brian.=C2=A0

In my staged copy, I've added a reference to RFC7230, which ac= cording to IANA holds the definition of the https scheme.=C2=A0 Will be= included in the next update.

I also verified that = our Section 2 includes "NOT RECOMMENDED" per the errata.



=

On Wed, May 24, 2= 017 at 9:20 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Wed, May 24, 2017, at 05:17 PM, Brian Campbel= l wrote:
As far as I can tell, '=
NOT RECOMMENDED' is fine per RFC 2119.







4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED&qu=
ot; mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.


And also this errata notes that NOT RECOMMENDED should be in the=
 first part of the abstract https://www.rfc-editor=
.org/errata_search.php?rfc=3D2119&eid=3D499

Never mind then!


On Wed, May 24, 2017 at 9:27 AM, Alexey Melnikov <aamelniko= v@fastmail.fm> wrote:
Alexey Melnikov has entered the = following ballot position for
draft-ietf-oauth-native-apps-11: No Objection

When responding, please keep the subject line intact and reply to all=
email addresses included in the To and CC lines. (Feel free to cut th= is
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A couple of nits:

8.2.=C2=A0 OAuth Implicit Grant Authorization Flow

=C2=A0 =C2=A0The OAuth 2.0 implicit grant authorization flow as defin= ed in
=C2=A0 =C2=A0Section 4.2 of OAuth 2.0 [RFC6749] generally works with = the practice
=C2=A0 =C2=A0of performing the authorization request in the browser, = and
receiving
=C2=A0 =C2=A0the authorization response via URI-based inter-app commu= nication.
=C2=A0 =C2=A0However, as the Implicit Flow cannot be protected by PKC= E (which is
a
=C2=A0 =C2=A0required in Section 8.1), the use of the Implicit Flow w= ith native
=C2=A0 =C2=A0apps is NOT RECOMMENDED.

NOT RECOMMENDED is not actually a construct allowed by RFC 2119, I th= ink
you should reword it using "SHOULD NOT".

It would be good to add RFC reference for HTTPS URIs.


_______________________________________________
OAuth mailing list


--001a1143e36abc97d70550f04130-- From nobody Thu Jun 1 18:44:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73602129A9C for ; Thu, 1 Jun 2017 18:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6NFlQJodL0p for ; Thu, 1 Jun 2017 18:44:12 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 D06B012948B for ; Thu, 1 Jun 2017 18:44:11 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id o12so46979026iod.3 for ; Thu, 01 Jun 2017 18:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3uwXce9e4fgL/0HF3Cx/Cwe6KqYfZDNMBxAWWZX4KaY=; b=v8UFgEWW+JhDEjnra85FoqUD/c+UIbSzCRJqqDY22YCgnKS8rpAq5Z43SOwkWHhB1q Y4rjTIaET+ZZQQx9XP4wC7Yp7AKcPCO3I/Ni8g59jdLSDrf1WWii/568IV473JZzdki/ AXt89HvDe+1E6rweayVc2By8VVoNSm9J091zx7YPSFFdNKR48AS0Uq9mcNFnJkPb9NW9 p83noHMwHbLPnssAAH8rAXTRRobVklIYSavs7iRUgxCh1ixIyeC4qGJl/iHVU4nPcZHf OdXq3KCyFoCGmzEb/xJqGajaPXWpfm89bk9adcMjFHdlTpno2ns0P+0k/wCXJiVmNQvt Zbew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3uwXce9e4fgL/0HF3Cx/Cwe6KqYfZDNMBxAWWZX4KaY=; b=V5E3+9Rx1DZdgjXacTgkSYiIXSEBTzIJtyBG0DxzkadwgD485K2svgtPxfSX+Tn6XO TK1zqHgQQzyE1DCBz/dRUyUcpMqrhajtIkNWXzEWimvSplPmGoJtLsvjMwAj7FmZZ6Ub /qt4gh1pLyL7YzW4T3IoyfNb4euBF9X4YfzAly/FRPbERO8OiQP9hr7Z22Q3O/S7uFTt KTee58mqFGNoELLOEgEGe0U1wm6wc0ADRpHdpfE+jLCqy1krpem9EDBkH0kbBASB+bsk HidTNiEHbkuW5jH/kxzuf9dRrSI70ZIhB14KiKqpC8N6EHmVadxRL8fq/cYlaDEVcUEL z8HA== X-Gm-Message-State: AODbwcCXCcuDP9NR5QQ0+b8wm52gRORmew+boeB/xnwRt1rnmBO00HKQ dUfDu+2/84D66B2w65UUZiZh1RFyM66W X-Received: by 10.107.51.195 with SMTP id z186mr5407171ioz.126.1496367850844; Thu, 01 Jun 2017 18:44:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.37 with HTTP; Thu, 1 Jun 2017 18:43:50 -0700 (PDT) In-Reply-To: <149546910687.10043.16893686894193706023.idtracker@ietfa.amsl.com> References: <149546910687.10043.16893686894193706023.idtracker@ietfa.amsl.com> From: William Denniss Date: Thu, 1 Jun 2017 18:43:50 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a11452ea034c4a30550f04ad5" Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-oauth-native-apps-11=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 01:44:13 -0000 --001a11452ea034c4a30550f04ad5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Mirja for your review. Version 12 when posted will be marked as updating RFC6749. On Mon, May 22, 2017 at 9:05 AM, Mirja K=C3=BChlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-oauth-native-apps-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Quick question just to double-check: should this document update RFC6749? > > > --001a11452ea034c4a30550f04ad5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you=C2=A0Mirja for your review. Version 12 when post= ed will be marked as updating=C2=A0RFC6749= .

On = Mon, May 22, 2017 at 9:05 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net<= /a>> wrote:
Mirja K=C3=BChlewin= d has entered the following ballot position for
draft-ietf-oauth-native-apps-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/= draft-ietf-oauth-native-apps/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Quick question just to double-check: should this document update RFC6749?


--001a11452ea034c4a30550f04ad5-- From nobody Fri Jun 2 05:08:48 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CE812EB66 for ; Fri, 2 Jun 2017 05:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPHnYx6tjYTT for ; Fri, 2 Jun 2017 05:08:42 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 0CFFC12950B for ; Fri, 2 Jun 2017 05:08:42 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id p62so3902818vkp.0 for ; Fri, 02 Jun 2017 05:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t/N+Sh+MWU4iNgVUQWJyHpuBO0WCGtc8qYxLeP4iXXU=; b=BBX3CyTzLKjgP+xzbDCJ5yKHUz6XbQQpOoa/NHqPSupxnPQ4yB+bPoVeSi/1FLh/x6 tIH/dNEl/L32Arniv46TsIiUjL8lWsXteNH1FUY0P06CQ7TgzZ1S9fF/QtO1Vw27RGuv eVcgyUvwhJe7GCjp71oAq/RQQigNJLNfSwY3RkFtsB9dz8poVTdPri+kbE04TCGwflcZ 9FOYk5QZ/+GzkdZk3LKlLji2T1oj3r4C2LHgIhgCseiIhuQ5FLwMiJxn1x3PBzGSzTp8 tLJFef2I5EokE2qd8wOZrjqdw1FIRBvYrrE63j5NfxNGRarjJGjlQ4EX5wKZSa3o/UmL LsVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t/N+Sh+MWU4iNgVUQWJyHpuBO0WCGtc8qYxLeP4iXXU=; b=ZXy8+T3XzxPG5OQ8mQ8vlHoz97JfIs/W/Hy6js3Ty6iG8uMtnBVDTshg8Y7KNm48Yj 56+mmHVPq8Z3QZ8O/8sr5hjtNjt0fRNmTye0rs5fFjmNel5EDYGFYn2qomhWzdly3rxY 0t7XdGc/C4L9EbBI9wDl9/ohI63lVXPc8PZhsWLoNIwzvo2e16JzGS5zWnw8gNtcI/M8 JxpDGRqoScg8l2i6Vw0U7SkjCfknAoZDid1m/XDEqllj++pr3nAQ6jm7Se6fE4ro49XN eq3hSas3S2DgyTs5VfTU7NHRKbj0hAXunUCyqRWfUmyNiQCWS1w1X1C6jJmjhkwMDSC9 Bp2g== X-Gm-Message-State: AODbwcBruJ3eG9sX2V3TKvHfHwTUoPVb8xAUKkNKpmjmJECjUv8qIQtf 4qgL3o51GaKH8Xc+EkNKgvLOEGaPlg== X-Received: by 10.31.85.198 with SMTP id j189mr1858688vkb.45.1496405320885; Fri, 02 Jun 2017 05:08:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.91 with HTTP; Fri, 2 Jun 2017 05:08:40 -0700 (PDT) In-Reply-To: References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> <58cc229c-ca5e-18d4-8b62-fbb3853f5cca@free.fr> From: Rifaat Shekh-Yusef Date: Fri, 2 Jun 2017 08:08:40 -0400 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="001a114e4040979a830550f90316" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 12:08:46 -0000 --001a114e4040979a830550f90316 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian, We did not see any objection to this latest proposal. Can you please go ahead and publish version -08 of the draft? We would like to start a WGLC on the new version. Regards, Rifaat On Fri, May 26, 2017 at 6:21 PM, Brian Campbell wrote: > Following up on this, I'd like to propose a different and less invasive > change to the "actor_token" text. The new wording is below and not much > different than the text in the current draft. Barring any solid objection= s > to this in the next week or so, I'll publish -08 at which point I believe > the document will be ready for WGLC. > > actor_token > > OPTIONAL. A security token that represents the identity of the acting > party. Typically this will be the party that is authorized to use the > requested security token and act on behalf of the subject. > > > > On Thu, May 11, 2017 at 9:58 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> The token exchange framework facilitates deployments like this one >> https://help.salesforce.com/articleView?id=3Dremoteaccess_oaut >> h_asset_token_flow.htm or https://developer.box.com/docs >> /getting-started-with-new-box-view, for example, and I don't think pure >> plug and play interoperability is a realistic goal. The framework promot= es >> interoperability in the form of common patterns and parameters that can = be >> supported in libraries, products, and services. >> >> There's not one "other case" I have in mind but rather just broadening >> the text somewhat to more straightforwardly accommodate other cases. On= e >> potential example is where the actor_token represents an authorizing par= ty >> (again maybe needed for policy or auditing) to the token exchange event >> itself rather than the party that's having access rights assigned to it >> (implicitly with impersonation or explicitly with delegation). >> >> >> >> On Tue, May 9, 2017 at 9:55 AM, Denis wrote: >> >>> Brian, >>> >>> Even if Token Exchange is a framework, the goal is to be finally able t= o >>> interoperate. >>> >>> Whether we have one or two parameters, would you be able to provide a >>> precise semantics for the "other case" you have in mind ? >>> >>> Denis >>> >>> Yes, I omitted your comments in that post because I'd previously replie= d >>> to you in a separate message where I said that the "actor_token is a >>> security token so that's not an issue that needs to be addressed." >>> https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html >>> >>> The other point you've just made about having very precise semantics fo= r >>> a field is a fair one. However, I wanted to avoid introducing yet anoth= er >>> field (or really two fields b/c of the associated *_type for each inbou= nd >>> token field), for what felt like a minor semantic variation that could = be >>> easily accommodated by the existing framework, to the draft that alread= y >>> has a lot of options and parameters on the request. And Token Exchange >>> really is a framework. I think that, to some extent, the framework is a= bit >>> of a Rorschach test for deployers and implementers to utilize to solve >>> their specific issues and needs. I expect that will be the case regardl= ess. >>> And I am proposing to somewhat genericize the text around one request >>> parameter to be more reflective of that. >>> >>> I would like to hear from others in the WG though. >>> >>> On Tue, May 9, 2017 at 3:06 AM, Denis wrote: >>> >>>> Brian, >>>> >>>> You omitted to include my comments in this post. So here it is again: >>>> >>>> =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=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 >>>> >>>> The current text is: >>>> >>>> actor_token OPTIONAL. A security token that represents the identity of >>>> the party that is authorized to use the requested security token and a= ct on >>>> behalf of the subject. >>>> >>>> This sentence is indeed wrong since an actor-token is not a security >>>> token. >>>> >>>> So your proposed change does not solve this issue: actor_token >>>> OPTIONAL. A security token that represents the identity of the acting >>>> party. >>>> >>>> The current text states: >>>> >>>> Typically, in the request, the subject_token represents the identity o= f >>>> the party on behalf of whom >>>> the token is being requested while the actor_token represents the >>>> identity of the party to whom the access >>>> rights of the issued token are being delegated. >>>> >>>> Logically, the definition should be along the following lines: >>>> >>>> actor_token OPTIONAL. Indicates the identity of the party to whom the >>>> access rights of the issued token are being delegated. >>>> >>>> If there is no delegation, then this field (which is optional) will no= t >>>> be used. >>>> >>>> =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=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 >>>> >>>> I read your argumentation, but I maintain my comment. Each field shoul= d >>>> have a precise semantics. >>>> >>>> If you want to have another semantics, you should propose to define >>>> another field with its precise meaning. >>>> >>>> Denis >>>> >>>> Let me throw out a bit more context about this. The "actor_token" >>>> might, in a delegation scenario, represent the identity of the party t= o >>>> whom the access rights of the issued token are being delegated. That's= the >>>> typical delegation scenario that is discussed in the draft. However, t= he >>>> "actor_token" might also be utilized/needed by the AS in an impersonat= ion >>>> scenario for policy or auditing reasons even when the resulting issued >>>> token doesn't contain info about the delegation or actor. Similarly, t= he >>>> actor might not be strictly doing the impersonation but rather just be= a >>>> party (again maybe needed for policy or auditing) to the token exchang= e >>>> event itself. When I wrote the "actor_token" text in section 2.1 some= ~18 >>>> months ago I had the delegation scenario at the front of my mind and >>>> (clearly) intended to accommodate it. However, I didn't intend to limi= t it >>>> to only that and, looking at the text again, I think what is there now= is >>>> too prescriptive and narrow. Thus my proposing to generalize the text >>>> somewhat. >>>> >>>> >>>> >>>> >>>> On Mon, May 8, 2017 at 10:29 AM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> I do have one minor issue I'd like to raise that relates to some >>>>> conversations I've been a party to recently about implementations and >>>>> applications of token exchange. >>>>> >>>>> I think that the current text in =C2=A72.1 for the "actor_token" is o= verly >>>>> specific towards the delegation scenario. I'd propose the language be >>>>> generalized somewhat to allow more versatility in applications/deploy= ments >>>>> of the token exchange framework. Here's that text: >>>>> >>>>> actor_token >>>>> OPTIONAL. A security token that represents the identity of the >>>>> acting party. >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef < >>>>> rifaat.ietf@gmail.com> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> The last email from Brian addresses the multiple audiences/resources >>>>>> issue with an error code, and we did not see any objection to this a= pproach >>>>>> so far. >>>>>> >>>>>> >>>>>> *Authors,* >>>>>> >>>>>> Are there any other open issues with this draft? >>>>>> Do you believe it is ready for WGLC? >>>>>> >>>>>> Thanks, >>>>>> Rifaat & Hannes >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < >>>>>> bcampbell@pingidentity.com> wrote: >>>>>> >>>>>>> As mentioned during the Chicago meeting the "invalid_target" error >>>>>>> code that was added in -07 was intended to give the AS a standard w= ay to >>>>>>> reject request with multiple audiences/resources that it doesn't un= derstand >>>>>>> or is unwilling or unable to process based on policy or whatever cr= iteria . >>>>>>> It was intended as a compromise, of sorts, to allow for the multipl= e >>>>>>> resources/audiences in the request but provide an easy out for the = AS of >>>>>>> saying it can't be supported based on whatever implementation or se= curity >>>>>>> or policy it has. >>>>>>> >>>>>>> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura >>>>>>> wrote: >>>>>>> >>>>>>>> There are cases where tokens are supposed to be consumed at >>>>>>>> multiple places and the `aud` needed to capture them. That's why `= aud` is a >>>>>>>> multi-valued field. >>>>>>>> >>>>>>>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >>>>>>>> torsten@lodderstedt.net> wrote: >>>>>>>> >>>>>>>>> May I ask you to explain this reason? >>>>>>>>> >>>>>>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones < >>>>>>>>> Michael.Jones@microsoft.com>: >>>>>>>>> >>>>>>>>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi= -valued in JWTs, >>>>>>>>> the audience needs to stay multi-valued in Token Exchange. Ditto= for >>>>>>>>> resources. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -- Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org >>>>>>>>> ] *On Behalf Of *Brian Campbell >>>>>>>>> *Sent:* Monday, March 27, 2017 8:45 AM >>>>>>>>> *To:* Torsten Lodderstedt >>>>>>>>> *Cc:* oauth >>>>>>>>> *Subject:* Re: [OAUTH-WG] I-D Action: >>>>>>>>> draft-ietf-oauth-token-exchange-07.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for the review and question, Torsten. >>>>>>>>> >>>>>>>>> The desire to support multiple audience/resource values in the >>>>>>>>> request came up during a review and discussion among the authors = of the >>>>>>>>> document when preparing the -03 draft. As I recall, it was said t= hat both >>>>>>>>> Salesforce and Microsoft had use-cases for it. I incorporated sup= port for >>>>>>>>> it into the draft acting in the role of editor. >>>>>>>>> >>>>>>>>> From an individual perspective, I tend to agree with you that >>>>>>>>> allowing for multiple audiences/resources adds a lot of complexit= y that's >>>>>>>>> like not needed in many (or most) cases. And I would personally b= e open to >>>>>>>>> making audience and resource mutual exclusive and single valued. = A question >>>>>>>>> for the WG I suppose. >>>>>>>>> >>>>>>>>> The "invalid_target" error code that was added in -07 was intende= d >>>>>>>>> to give the AS a standard way to deal with the complexity and rej= ect >>>>>>>>> request with multiple audiences/resources that it doesn't underst= and or is >>>>>>>>> unwilling or unable to process. It was intended as a compromise, = of sorts, >>>>>>>>> to allow for the multiples but provide an easy out of saying it c= an't be >>>>>>>>> supported based on whatever implementation or policy of the AS. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>>>>>>>> torsten@lodderstedt.net> wrote: >>>>>>>>> >>>>>>>>> Hi Brian, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> thanks for the clarification around resource, audience and scope. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Here are my comments on the draft: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameters= may be >>>>>>>>> used to indicate >>>>>>>>> >>>>>>>>> that the issued token is intended to be used at the multipl= e >>>>>>>>> >>>>>>>>> resources listed.=E2=80=9C >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Can you please explain the rational in more detail? I don=E2=80= =99t >>>>>>>>> understand why there is a need to ask for access tokens, which ar= e good for >>>>>>>>> multiple resources at once. This is a request type more or less e= xclusively >>>>>>>>> used in server to server scenarios, right? So the only reason I c= an think >>>>>>>>> of is call reduction. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On the other side, this feature increases the AS's complexity, >>>>>>>>> e.g. its policy may prohibit to issue tokens for multiple resourc= es in >>>>>>>>> general or the particular set the client is asking for. How shall= the AS >>>>>>>>> handles such cases? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> And it is getting even more complicated given there could also be >>>>>>>>> multiple audience values and the client could mix them: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> "Multiple "audience" parameters >>>>>>>>> >>>>>>>>> may be used to indicate that the issued token is intended t= o >>>>>>>>> be >>>>>>>>> >>>>>>>>> used at the multiple audiences listed. The "audience" and >>>>>>>>> >>>>>>>>> "resource" parameters may be used together to indicate >>>>>>>>> multiple >>>>>>>>> >>>>>>>>> target services with a mix of logical names and physical >>>>>>>>> >>>>>>>>> locations.=E2=80=9C >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> And in the end the client may add some scope values to the =E2=80= =9Emeal=E2=80=9C, >>>>>>>>> which brings us to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> =E2=80=9EEffectively, the requested access rights of the >>>>>>>>> >>>>>>>>> token are the cartesian product of all the scopes at all the >>>>>>>>> target >>>>>>>>> >>>>>>>>> services." >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I personally would suggest to drop support for multiple audience >>>>>>>>> and resource parameters and make audience and resource mutual exc= lusive. I >>>>>>>>> think this is sufficient and much easier to implement. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> kind regards, >>>>>>>>> >>>>>>>>> Torsten. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>>>>>>>> bcampbell@pingidentity.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The >>>>>>>>> primary change in -07 is the addition of a description of the rel= ationship >>>>>>>>> between audience/resource/scope, which was a request or comment t= hat came >>>>>>>>> up during the f2f meeting in Seoul. >>>>>>>>> >>>>>>>>> Excerpted from the Document History: >>>>>>>>> >>>>>>>>> -07 >>>>>>>>> >>>>>>>>> o Fixed typo (desecration -> discretion). >>>>>>>>> o Added an explanation of the relationship between scope, >>>>>>>>> audience >>>>>>>>> and resource in the request and added an "invalid_target" >>>>>>>>> error >>>>>>>>> code enabling the AS to tell the client that the requested >>>>>>>>> audiences/resources were too broad. >>>>>>>>> >>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>> From: >>>>>>>>> Date: Wed, Jan 11, 2017 at 12:00 PM >>>>>>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>>>>>>> e-07.txt >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> Cc: oauth@ietf.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s >>>>>>>>> directories. >>>>>>>>> This draft is a work item of the Web Authorization Protocol of th= e >>>>>>>>> IETF. >>>>>>>>> >>>>>>>>> Title : OAuth 2.0 Token Exchange >>>>>>>>> Authors : Michael B. Jones >>>>>>>>> Anthony Nadalin >>>>>>>>> Brian Campbell >>>>>>>>> John Bradley >>>>>>>>> Chuck Mortimore >>>>>>>>> Filename : draft-ietf-oauth-token-exchange-07.txt >>>>>>>>> Pages : 31 >>>>>>>>> Date : 2017-01-11 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> This specification defines a protocol for an HTTP- and JSON- >>>>>>>>> based >>>>>>>>> Security Token Service (STS) by defining how to request and >>>>>>>>> obtain >>>>>>>>> security tokens from OAuth 2.0 authorization servers, includin= g >>>>>>>>> security tokens employing impersonation and delegation. >>>>>>>>> >>>>>>>>> >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >>>>>>>>> >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> >>>>>>>>> >>>>>>>>> ... > > [Message clipped] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114e4040979a830550f90316 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian,

We did not see any ob= jection to this latest proposal.

Can you please go= ahead and publish version -08 of the draft?
We would like to sta= rt a WGLC on the new version.

Regards,
= =C2=A0Rifaat


On Fri, May 26, 2017 at 6:21 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Following up on this, I'd like to propos= e a different and less invasive change to the "actor_token" text.= The new wording is below and not much different than the text in the curre= nt draft. Barring any solid objections to this in the next week or so, I= 9;ll publish -08 at which point I believe the document will be ready for WG= LC.

actor_token

OPTIONA= L.=C2=A0 A security token that represents the identity of the acting party.= Typically this will be the party that is authorized to use the requested s= ecurity token and act on behalf of the subject.



On T= hu, May 11, 2017 at 9:58 AM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:
The token exchange framework facilitates d= eployments like this one https://he= lp.salesforce.com/articleView?id=3Dremoteaccess_oauth_asset_token= _flow.htm or https://developer.box.com/docs/ge= tting-started-with-new-box-view, for example, and I don't thin= k pure plug and play interoperability is a realistic goal. The framework pr= omotes interoperability in the form of common patterns and parameters that = can be supported in libraries, products, and services.

There&= #39;s not one "other case" I have in mind but rather just broaden= ing the text somewhat to more straightforwardly accommodate other cases.=C2= =A0 One potential example is where the actor_token represents an authorizin= g party (again maybe needed for policy or auditing) to the token exchange event itself rather than the party that's having access rights assigne= d to it (implicitly with impersonation or explicitly with delegation).
=


On Tue, May 9, 2017 at 9:55 AM, Denis <denis.ietf@free.fr>= wrote:
=20 =20 =20
Brian,

Even if Token Exchange is a framework, the goal is to be finally able to interoperate.

Whether we have one or two parameters, would you be able to provide a precise semantics for the "other case" you have i= n mind ?

Denis

Yes, I omitted your comments in that post because I'd previously replied to you in a separate message where I said that the "actor_token is a security token so that's not = an issue that needs to be addressed."=C2=A0 https://www.ietf.org/mail-archive/web/oauth/current/msg17247.ht= ml

The other point you've just made about having very precise semantics for a field is a fair one. However, I wanted to avoid introducing yet another field (or really two fields b/c of the associated *_type for each inbound token field), for what felt like a minor semantic variation that could be easily accommodated by the existing framework, to the draft that already has a lot of options and parameters on the request. And Token Exchange really is a framework. I think that, to some extent, the framework is a bit of a Rorschach test for deployers and implementers to utilize to solve their specific issues and needs. I expect that will be the case regardless. And I am proposing to somewhat genericize the text around one request parameter to be more reflective of that.

I would like to hear from others in the WG though.

On Tue, May 9, 2017 at 3:06 AM, Denis <denis.ietf@free.fr> wrote:
Brian,

You omitted to include my comments in this post. So here it is again:

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

The current text is:

actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token=C2=A0 OPTIONAL.=C2=A0 A security token that represents the identity of the acting party.

The current text states:
Typically, in the request, the subject_token represents the identity of the party on behalf of whom
 the token is being requested while the actor_token represents the identity of the party to whom the access
rights of the issued token are being delegated.
Logically, the definition should be along the following lines:

=C2=A0actor_token OPTIONAL. Indic= ates the identity of the party to whom the access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not be used.

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

I read your argumentation, but I maintain my comment. Each field should have a precise semantics.

If you want to have another semantics, you should propose to define another field with its precise meaning.

Denis

Let me throw out a bit more context about this. The "actor_token" might, in a delegation scenario, represent the identity of the party to whom the access rights of the issued token are being delegated. That's the typical delegation scenario that is discussed in the draft. However, the "actor_token" might als= o be utilized/needed by the AS in an impersonation scenario for policy or auditing reasons even when the resulting issued token doesn't contain info about the delegation or actor. Similarly, the actor might not be strictly doing the impersonation but rather just be a party (again maybe needed for policy or auditing) to the token exchange event itself.=C2=A0 When I wrote the "actor_token" text in section 2.1 some ~18 = months ago I had the delegation scenario at the front of my mind and (clearly) intended to accommodate it. However, I didn't intend to limit it to only that and, looking at the text again, I think what is there now is too prescriptive and narrow. Thus my proposing to generalize the text somewhat.




On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:
I do have one minor issue I'd like to raise that relates to some conversations I've been a party to recently about implementations and applications of token exchange.

I think that the current text in =C2=A72.1 for the "actor_token" is overly spe= cific towards the delegation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text:

=C2=A0=C2=A0 actor_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2= =A0 A security token that represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 acting party.= =C2=A0




On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far.


Authors,

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
=C2=A0Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <b= campbell@pingidentity.com> wrote:
As mentioned during the Chicago meeting the "invalid_target" = error code that was added in -07 was intended to give the AS a standard way to reject request with multiple audiences/resources that it doesn't understand o= r is unwilling or unable to process based on policy or whatever criteria . It was intended as a compromise, of sorts, to allow for the multiple resources/audiences in the request but provide an easy out for the AS of saying it can't be supported based on whatever implementation or security or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@= gmail.com> wrote:
Th= ere are cases where tokens are supposed to be consumed at multiple places and the `aud` needed to capture them. That's why `aud` is a multi-valued field.=C2=A0

= On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@microsoft.com<= /a>>:

For the same reason that the =E2=80=9Caud= =E2=80=9D claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.=C2=A0 Ditto for resources.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=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 [mailto:oauth-bounces@ietf.org<= /a>] On Behalf Of Bri= an Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net><= br class=3D"m_-8610107656712704476gmail-m_-6853265654903375744m_-5500081355= 606695985m_8684407748554078058m_6905276776273010841m_4803735329627533709m_-= 2675142197049852080m_3983298834558915277m_-4354184635220679769gmail_msg"> Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-= token-exchange-07.txt

=C2=A0

Thanks for the review and q= uestion, Torsten.

The desire to support multi= ple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.

From an individual perspect= ive, I tend to agree with you that allowing for multiple audiences/resourc= es adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to= give the AS a standard way to deal with the complexity and reject request with multiple audiences/resourc= es that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

=C2=A0

=C2=A0

=C2=A0

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi Brian,

=C2=A0

thanks for the clarification around resource, audience and scope.=C2=A0

=C2=A0

Here are my comments on the draft:

=C2=A0

In section 2.1 it states: =E2=80=9EMultiple "resource&qu= ot; parameters may be used to indicate

=C2=A0 =C2=A0 =C2=A0 tha= t the issued token is intended to be used at the multiple

=C2=A0 =C2=A0 =C2=A0 res= ources listed.=E2=80=9C<= /p>

=C2=A0

Can you please explain the rational in more detail? I don=E2=80=99t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction.=C2=A0<= /p>

=C2=A0

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

=C2=A0

And it is getting even more complicated given there could also be multiple audience values and the client could mix them:=C2=A0

=C2=A0

"Multiple "audience&qu= ot; parameters

=C2=A0 =C2=A0 =C2=A0 may= be used to indicate that the issued token is intended to be

=C2=A0 =C2=A0 =C2=A0 use= d at the multiple audiences listed.=C2=A0 The "audience&qu= ot; and

=C2=A0 =C2=A0 =C2=A0 &qu= ot;resource" parameters may be used together to indicate multiple

=C2=A0 =C2=A0 =C2=A0 tar= get services with a mix of logical names and physical

=C2=A0 =C2=A0 =C2=A0 locations.=E2=80= =9C

=C2=A0

And in the end the client may add some scope values to the =E2=80=9Emeal=E2= =80=9C, which brings us to=C2= =A0

=C2=A0

=E2=80=9EEffectively, the requested access rights of the

=C2=A0 =C2=A0token are t= he cartesian product of all the scopes at all the target

=C2=A0 =C2=A0services.&q= uot;

=C2=A0

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

=C2=A0

kind regards,

Torsten.

=C2=A0

=C2=A0

Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com>:

=C2=A0

Draft -07 of "OAuth 2.= 0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource= /scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

=C2=A0=C2=A0 -07<= br class=3D"m_-8610107656712704476gmail-m_-6853265654903375744m_-5500081355= 606695985m_8684407748554078058m_6905276776273010841m_4803735329627533709m_-= 2675142197049852080m_3983298834558915277m_-4354184635220679769gmail_msg">
=C2=A0=C2=A0 o=C2= =A0 Fixed typo (desecration -> discretion).
=C2=A0=C2=A0 o=C2= =A0 Added an explanation of the relationship between scope, audience
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and resource in the request and added an "invalid_tar= get" error
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 code enabling the AS to tell the client that the requested
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 audiences/resourc= es were too broad.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-= token-exchange-07.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: OAuth 2.0 Token Exchange =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Authors=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: Michael B= . Jones
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Brian Campbell =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Chuck Mortimore
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Filename=C2=A0 = =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-= token-exchange-07.txt
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 31
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : 2017-01-11

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- based
=C2=A0 =C2=A0Secu= rity Token Service (STS) by defining how to request and obtain
=C2=A0 =C2=A0secu= rity tokens from OAuth 2.0 authorization servers, including
=C2=A0 =C2=A0secu= rity tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
h= ttps://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/<= /a>

There's also = a htmlized version available at:
=

=
<= /div>
...

[Message clipped]=C2=A0= =C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a114e4040979a830550f90316-- From nobody Fri Jun 2 11:51:57 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0728129B69; Fri, 2 Jun 2017 11:51:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149642950881.31800.5389590172381871795@ietfa.amsl.com> Date: Fri, 02 Jun 2017 11:51:48 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 18:51:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-08.txt Pages : 31 Date : 2017-06-02 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-08 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 Jun 2 12:06:02 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDA3126CB6 for ; Fri, 2 Jun 2017 12:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmE2d2GmH0g2 for ; Fri, 2 Jun 2017 12:05:59 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 27199127077 for ; Fri, 2 Jun 2017 12:05:59 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id x47so50007557uab.0 for ; Fri, 02 Jun 2017 12:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8tpetrijxMlSOf/rc/Vvl/CXQgNSe9+wBwlG5ixwCfM=; b=i9UI1F/G0c0onxR9dTHF1dS0U0xFcf6tfABArqOGApFun89thDSAFrmk5RFPp3qkri bBccC128BGUQ4pbIBh5MCivrJDQ0+jNmBPvHWOTpt7w9AzP26OW1fI2JE7dwgL7z+vjl 2b1nofkcZfKbCnmj8hQXhq1GUuxn0JhWaoje2A2CO6laziUkwGg1lZHsTWfOTGYkp2wL MHGXVcSrE7Gv5RDm8S5dwPKKMcdRxKgIZxVwRiJNrkdJY+Trv+hN3vBZLYZxF7ZEE5Yi 1VU1rD+gHr+By/bGmfAyjtYohLrJj+JxKIvAMvODYA3ST+eUKv70jAtvSH3LWPCgVjTX 0bLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8tpetrijxMlSOf/rc/Vvl/CXQgNSe9+wBwlG5ixwCfM=; b=XWtoX0BJ4sdHaYNZmYKcJc5Yftpj3mtOlI9zSt6Czz0EjCpR3dbrx/i1pPLMLQSuWN LLPaB78MHsdPIT2rlgIkbz3S+52uTm/I8NDXaMyivvULAXkY1xO+X8wNVtK+x9Re3tv4 MahrMwyZ8HN9JZbiedjHl/X4GcDewPB6Q/ZCl3DSRCyUG4AbvbxGN29NaTn4kGTYHGKM nsWQh5y0BzKEAw/90vsHAe2xfaHzHE9MWgUKNfpzQI7i3hXHqVrTzP99u6LAvGnDpE0S LId6n4+rhdbC40Fu2NBk8vFEi+pxGmAtPAeWAGCOTR7x2voL1q8XNdQJPYwPw5i7C5c4 GDeA== X-Gm-Message-State: AODbwcCJFIxrT0Gwa1pEY3JQF86DDRm2aIm/fAQ2kJ4QMwBYgkEXNbBE gBCdZXkaj3IrdcTEGIeslJB2g331nYPL X-Received: by 10.176.6.197 with SMTP id g63mr4553613uag.52.1496430358035; Fri, 02 Jun 2017 12:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.91 with HTTP; Fri, 2 Jun 2017 12:05:57 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Fri, 2 Jun 2017 15:05:57 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c122e64ec2b970550fed769" Archived-At: Subject: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 19:06:00 -0000 --94eb2c122e64ec2b970550fed769 Content-Type: text/plain; charset="UTF-8" All, We are starting a WGLC on the Token Exchange document: https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 Please, review the document and provide feedback on any issues you see with the document. The WGLC will end in two weeks, on June 17, 2017. Regards, Rifaat and Hannes --94eb2c122e64ec2b970550fed769 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We are starting a WGLC = on the Token Exchange document:

Please, review the docum= ent and provide feedback on any issues you see with the document.

The WGLC will end in two weeks, on June 17, 2017.

Regards,
=C2=A0Rifaat and Hannes

--94eb2c122e64ec2b970550fed769-- From nobody Fri Jun 2 12:20:08 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2B1293E9 for ; Fri, 2 Jun 2017 12:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00noHgw2qTNM for ; Fri, 2 Jun 2017 12:20:00 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 753FC12896F for ; Fri, 2 Jun 2017 12:20:00 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id m17so55750810pfg.3 for ; Fri, 02 Jun 2017 12:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xSw+TBtdBiLuKVWpsYygfD2w5MAX9QHB/SaWiqCPuhU=; b=YGmH4qMhCYBMrpbmochgT3P58JtlK3KFMogVVSymyei6B9h0Cc4b1pLiqQmaoxmgPx EAJ1FwVyObeF20/ecrXtn8hrmGpEummVNzEXiJ8avXM7xooc9uHWJqjHxPKCi2eDnzck gc06/QENsYwbITD0REikiBBcfDr71B5PWpj/o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xSw+TBtdBiLuKVWpsYygfD2w5MAX9QHB/SaWiqCPuhU=; b=hjMmTNGXyPLuIaVd4ZblEvlMCTlndlM8k0U0390zc0e6VBIsHMx3fTOzgeF7eQoN80 rz4jyIAXR+YpEu0kk/shJDH7BgWPLevCJR8nVdvY06WSdYOCz3aNOGbyMYxYYKlyeUKd puU+EhkqCLt8UEDOo/xrFIwfT9jkjdOySIWOZ1BTViuC31l8FHqo0O4DzY/u2yuadyBr tRq0ddKopG8PJx/oSO7ZLfGWU90/9BW3/ITEWWboOSVayl17AkM5emFhfL6mYTAqoGPU bRweYXLYi11N6DLph8G8BW3xHEMmUnmU/gzz+6Q91pZK/8RGMuhac/w2KVGBkxW1Tz9T 2ggg== X-Gm-Message-State: AODbwcBG0bbXfFs46laJkuQHVuDXz52IjAdAqKp1Ekw2DNd9fh/0ELEj E7jb2uJXhVUycQHRUQ2dJmttmwztS2gAOTNEhcMzEwd94fNeCTThqWU63pzZWPDuebkmalMtN3a 2NRkYJVI= X-Received: by 10.98.7.149 with SMTP id 21mr8196275pfh.54.1496431199882; Fri, 02 Jun 2017 12:19:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.149.4 with HTTP; Fri, 2 Jun 2017 12:19:29 -0700 (PDT) In-Reply-To: References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> <58cc229c-ca5e-18d4-8b62-fbb3853f5cca@free.fr> From: Brian Campbell Date: Fri, 2 Jun 2017 13:19:29 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="001a1143e26219b6730550ff0a77" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 19:20:05 -0000 --001a1143e26219b6730550ff0a77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure thing Rifaat, here it is: https://mailarchive.ietf.org/arch/msg/oauth/svrY2VEiYAJClftN8y1oQ1p4rVw On Fri, Jun 2, 2017 at 6:08 AM, Rifaat Shekh-Yusef wrote: > Brian, > > We did not see any objection to this latest proposal. > > Can you please go ahead and publish version -08 of the draft? > We would like to start a WGLC on the new version. > > Regards, > Rifaat > > > On Fri, May 26, 2017 at 6:21 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Following up on this, I'd like to propose a different and less invasive >> change to the "actor_token" text. The new wording is below and not much >> different than the text in the current draft. Barring any solid objectio= ns >> to this in the next week or so, I'll publish -08 at which point I believ= e >> the document will be ready for WGLC. >> >> actor_token >> >> OPTIONAL. A security token that represents the identity of the acting >> party. Typically this will be the party that is authorized to use the >> requested security token and act on behalf of the subject. >> >> >> >> On Thu, May 11, 2017 at 9:58 AM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> The token exchange framework facilitates deployments like this one >>> https://help.salesforce.com/articleView?id=3Dremoteaccess_oaut >>> h_asset_token_flow.htm or https://developer.box.com/docs >>> /getting-started-with-new-box-view, for example, and I don't think pure >>> plug and play interoperability is a realistic goal. The framework promo= tes >>> interoperability in the form of common patterns and parameters that can= be >>> supported in libraries, products, and services. >>> >>> There's not one "other case" I have in mind but rather just broadening >>> the text somewhat to more straightforwardly accommodate other cases. O= ne >>> potential example is where the actor_token represents an authorizing pa= rty >>> (again maybe needed for policy or auditing) to the token exchange event >>> itself rather than the party that's having access rights assigned to it >>> (implicitly with impersonation or explicitly with delegation). >>> >>> >>> >>> On Tue, May 9, 2017 at 9:55 AM, Denis wrote: >>> >>>> Brian, >>>> >>>> Even if Token Exchange is a framework, the goal is to be finally able >>>> to interoperate. >>>> >>>> Whether we have one or two parameters, would you be able to provide a >>>> precise semantics for the "other case" you have in mind ? >>>> >>>> Denis >>>> >>>> Yes, I omitted your comments in that post because I'd previously >>>> replied to you in a separate message where I said that the "actor_toke= n is >>>> a security token so that's not an issue that needs to be addressed." >>>> https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html >>>> >>>> The other point you've just made about having very precise semantics >>>> for a field is a fair one. However, I wanted to avoid introducing yet >>>> another field (or really two fields b/c of the associated *_type for e= ach >>>> inbound token field), for what felt like a minor semantic variation th= at >>>> could be easily accommodated by the existing framework, to the draft t= hat >>>> already has a lot of options and parameters on the request. And Token >>>> Exchange really is a framework. I think that, to some extent, the fram= ework >>>> is a bit of a Rorschach test for deployers and implementers to utilize= to >>>> solve their specific issues and needs. I expect that will be the case >>>> regardless. And I am proposing to somewhat genericize the text around = one >>>> request parameter to be more reflective of that. >>>> >>>> I would like to hear from others in the WG though. >>>> >>>> On Tue, May 9, 2017 at 3:06 AM, Denis wrote: >>>> >>>>> Brian, >>>>> >>>>> You omitted to include my comments in this post. So here it is again: >>>>> >>>>> =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=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 >>>>> >>>>> The current text is: >>>>> >>>>> actor_token OPTIONAL. A security token that represents the identity o= f >>>>> the party that is authorized to use the requested security token and = act on >>>>> behalf of the subject. >>>>> >>>>> This sentence is indeed wrong since an actor-token is not a security >>>>> token. >>>>> >>>>> So your proposed change does not solve this issue: actor_token >>>>> OPTIONAL. A security token that represents the identity of the actin= g >>>>> party. >>>>> >>>>> The current text states: >>>>> >>>>> Typically, in the request, the subject_token represents the identity >>>>> of the party on behalf of whom >>>>> the token is being requested while the actor_token represents the >>>>> identity of the party to whom the access >>>>> rights of the issued token are being delegated. >>>>> >>>>> Logically, the definition should be along the following lines: >>>>> >>>>> actor_token OPTIONAL. Indicates the identity of the party to whom >>>>> the access rights of the issued token are being delegated. >>>>> >>>>> If there is no delegation, then this field (which is optional) will >>>>> not be used. >>>>> >>>>> =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=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 >>>>> >>>>> I read your argumentation, but I maintain my comment. Each field >>>>> should have a precise semantics. >>>>> >>>>> If you want to have another semantics, you should propose to define >>>>> another field with its precise meaning. >>>>> >>>>> Denis >>>>> >>>>> Let me throw out a bit more context about this. The "actor_token" >>>>> might, in a delegation scenario, represent the identity of the party = to >>>>> whom the access rights of the issued token are being delegated. That'= s the >>>>> typical delegation scenario that is discussed in the draft. However, = the >>>>> "actor_token" might also be utilized/needed by the AS in an impersona= tion >>>>> scenario for policy or auditing reasons even when the resulting issue= d >>>>> token doesn't contain info about the delegation or actor. Similarly, = the >>>>> actor might not be strictly doing the impersonation but rather just b= e a >>>>> party (again maybe needed for policy or auditing) to the token exchan= ge >>>>> event itself. When I wrote the "actor_token" text in section 2.1 som= e ~18 >>>>> months ago I had the delegation scenario at the front of my mind and >>>>> (clearly) intended to accommodate it. However, I didn't intend to lim= it it >>>>> to only that and, looking at the text again, I think what is there no= w is >>>>> too prescriptive and narrow. Thus my proposing to generalize the text >>>>> somewhat. >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, May 8, 2017 at 10:29 AM, Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>>> I do have one minor issue I'd like to raise that relates to some >>>>>> conversations I've been a party to recently about implementations an= d >>>>>> applications of token exchange. >>>>>> >>>>>> I think that the current text in =C2=A72.1 for the "actor_token" is = overly >>>>>> specific towards the delegation scenario. I'd propose the language b= e >>>>>> generalized somewhat to allow more versatility in applications/deplo= yments >>>>>> of the token exchange framework. Here's that text: >>>>>> >>>>>> actor_token >>>>>> OPTIONAL. A security token that represents the identity of th= e >>>>>> acting party. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef < >>>>>> rifaat.ietf@gmail.com> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> The last email from Brian addresses the multiple audiences/resource= s >>>>>>> issue with an error code, and we did not see any objection to this = approach >>>>>>> so far. >>>>>>> >>>>>>> >>>>>>> *Authors,* >>>>>>> >>>>>>> Are there any other open issues with this draft? >>>>>>> Do you believe it is ready for WGLC? >>>>>>> >>>>>>> Thanks, >>>>>>> Rifaat & Hannes >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < >>>>>>> bcampbell@pingidentity.com> wrote: >>>>>>> >>>>>>>> As mentioned during the Chicago meeting the "invalid_target" error >>>>>>>> code that was added in -07 was intended to give the AS a standard = way to >>>>>>>> reject request with multiple audiences/resources that it doesn't u= nderstand >>>>>>>> or is unwilling or unable to process based on policy or whatever c= riteria . >>>>>>>> It was intended as a compromise, of sorts, to allow for the multip= le >>>>>>>> resources/audiences in the request but provide an easy out for the= AS of >>>>>>>> saying it can't be supported based on whatever implementation or s= ecurity >>>>>>>> or policy it has. >>>>>>>> >>>>>>>> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura >>>>>>>> wrote: >>>>>>>> >>>>>>>>> There are cases where tokens are supposed to be consumed at >>>>>>>>> multiple places and the `aud` needed to capture them. That's why = `aud` is a >>>>>>>>> multi-valued field. >>>>>>>>> >>>>>>>>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >>>>>>>>> torsten@lodderstedt.net> wrote: >>>>>>>>> >>>>>>>>>> May I ask you to explain this reason? >>>>>>>>>> >>>>>>>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones < >>>>>>>>>> Michael.Jones@microsoft.com>: >>>>>>>>>> >>>>>>>>>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is mult= i-valued in JWTs, >>>>>>>>>> the audience needs to stay multi-valued in Token Exchange. Ditt= o for >>>>>>>>>> resources. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -- Mike >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org >>>>>>>>>> ] *On Behalf Of *Brian Campbell >>>>>>>>>> *Sent:* Monday, March 27, 2017 8:45 AM >>>>>>>>>> *To:* Torsten Lodderstedt >>>>>>>>>> *Cc:* oauth >>>>>>>>>> *Subject:* Re: [OAUTH-WG] I-D Action: >>>>>>>>>> draft-ietf-oauth-token-exchange-07.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for the review and question, Torsten. >>>>>>>>>> >>>>>>>>>> The desire to support multiple audience/resource values in the >>>>>>>>>> request came up during a review and discussion among the authors= of the >>>>>>>>>> document when preparing the -03 draft. As I recall, it was said = that both >>>>>>>>>> Salesforce and Microsoft had use-cases for it. I incorporated su= pport for >>>>>>>>>> it into the draft acting in the role of editor. >>>>>>>>>> >>>>>>>>>> From an individual perspective, I tend to agree with you that >>>>>>>>>> allowing for multiple audiences/resources adds a lot of complexi= ty that's >>>>>>>>>> like not needed in many (or most) cases. And I would personally = be open to >>>>>>>>>> making audience and resource mutual exclusive and single valued.= A question >>>>>>>>>> for the WG I suppose. >>>>>>>>>> >>>>>>>>>> The "invalid_target" error code that was added in -07 was >>>>>>>>>> intended to give the AS a standard way to deal with the complexi= ty and >>>>>>>>>> reject request with multiple audiences/resources that it doesn't= understand >>>>>>>>>> or is unwilling or unable to process. It was intended as a compr= omise, of >>>>>>>>>> sorts, to allow for the multiples but provide an easy out of say= ing it >>>>>>>>>> can't be supported based on whatever implementation or policy of= the AS. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>>>>>>>>> torsten@lodderstedt.net> wrote: >>>>>>>>>> >>>>>>>>>> Hi Brian, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> thanks for the clarification around resource, audience and scope= . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here are my comments on the draft: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameter= s may be >>>>>>>>>> used to indicate >>>>>>>>>> >>>>>>>>>> that the issued token is intended to be used at the multip= le >>>>>>>>>> >>>>>>>>>> resources listed.=E2=80=9C >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Can you please explain the rational in more detail? I don=E2=80= =99t >>>>>>>>>> understand why there is a need to ask for access tokens, which a= re good for >>>>>>>>>> multiple resources at once. This is a request type more or less = exclusively >>>>>>>>>> used in server to server scenarios, right? So the only reason I = can think >>>>>>>>>> of is call reduction. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On the other side, this feature increases the AS's complexity, >>>>>>>>>> e.g. its policy may prohibit to issue tokens for multiple resour= ces in >>>>>>>>>> general or the particular set the client is asking for. How shal= l the AS >>>>>>>>>> handles such cases? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And it is getting even more complicated given there could also b= e >>>>>>>>>> multiple audience values and the client could mix them: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> "Multiple "audience" parameters >>>>>>>>>> >>>>>>>>>> may be used to indicate that the issued token is intended >>>>>>>>>> to be >>>>>>>>>> >>>>>>>>>> used at the multiple audiences listed. The "audience" and >>>>>>>>>> >>>>>>>>>> "resource" parameters may be used together to indicate >>>>>>>>>> multiple >>>>>>>>>> >>>>>>>>>> target services with a mix of logical names and physical >>>>>>>>>> >>>>>>>>>> locations.=E2=80=9C >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And in the end the client may add some scope values to the >>>>>>>>>> =E2=80=9Emeal=E2=80=9C, which brings us to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> =E2=80=9EEffectively, the requested access rights of the >>>>>>>>>> >>>>>>>>>> token are the cartesian product of all the scopes at all the >>>>>>>>>> target >>>>>>>>>> >>>>>>>>>> services." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I personally would suggest to drop support for multiple audience >>>>>>>>>> and resource parameters and make audience and resource mutual ex= clusive. I >>>>>>>>>> think this is sufficient and much easier to implement. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> kind regards, >>>>>>>>>> >>>>>>>>>> Torsten. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>>>>>>>>> bcampbell@pingidentity.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The >>>>>>>>>> primary change in -07 is the addition of a description of the re= lationship >>>>>>>>>> between audience/resource/scope, which was a request or comment = that came >>>>>>>>>> up during the f2f meeting in Seoul. >>>>>>>>>> >>>>>>>>>> Excerpted from the Document History: >>>>>>>>>> >>>>>>>>>> -07 >>>>>>>>>> >>>>>>>>>> o Fixed typo (desecration -> discretion). >>>>>>>>>> o Added an explanation of the relationship between scope, >>>>>>>>>> audience >>>>>>>>>> and resource in the request and added an "invalid_target" >>>>>>>>>> error >>>>>>>>>> code enabling the AS to tell the client that the requested >>>>>>>>>> audiences/resources were too broad. >>>>>>>>>> >>>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>>> From: >>>>>>>>>> Date: Wed, Jan 11, 2017 at 12:00 PM >>>>>>>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>>>>>>>> e-07.txt >>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>> Cc: oauth@ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>> Internet-Drafts directories. >>>>>>>>>> This draft is a work item of the Web Authorization Protocol of >>>>>>>>>> the IETF. >>>>>>>>>> >>>>>>>>>> Title : OAuth 2.0 Token Exchange >>>>>>>>>> Authors : Michael B. Jones >>>>>>>>>> Anthony Nadalin >>>>>>>>>> Brian Campbell >>>>>>>>>> John Bradley >>>>>>>>>> Chuck Mortimore >>>>>>>>>> Filename : draft-ietf-oauth-token-exchange-07.txt >>>>>>>>>> Pages : 31 >>>>>>>>>> >>>>>>>>>> ... > > [Message clipped] --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --001a1143e26219b6730550ff0a77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri,= Jun 2, 2017 at 6:08 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Brian,

We did not see any objection to this late= st proposal.

Can you please go ahead and publish v= ersion -08 of the draft?
We would like to start a WGLC on the new= version.

Regards,
=C2=A0Rifaat


On Fri, May 26, 2017 at 6:21 PM, B= rian Campbell <bcampbell@pingidentity.com> wrote:
Following up on this, I&#= 39;d like to propose a different and less invasive change to the "acto= r_token" text. The new wording is below and not much different than th= e text in the current draft. Barring any solid objections to this in the ne= xt week or so, I'll publish -08 at which point I believe the document w= ill be ready for WGLC.

actor_t= oken

OPTIONAL.=C2=A0 A security token that represents the identity o= f the acting party. Typically this will be the party that is authorized to = use the requested security token and act on behalf of the subject.

<= br>

On Thu, May 11, 2017 at 9:58 AM, Brian = Campbell <bcampbell@pingidentity.com> wrote:
There's not one "other case" = I have in mind but rather just broadening the text somewhat to more straigh= tforwardly accommodate other cases.=C2=A0 One potential example is where th= e actor_token represents an authorizing party (again maybe needed for polic= y or auditing) to the token exchange event itself rather than the party that's having access rights assigne= d to it (implicitly with impersonation or explicitly with delegation).
=


=20 =20 =20
B= rian,

Even if Token Exchange is a framework, the goal is to be finally able to interoperate.

Whether we have one or two parameters, would you be able to provide a precise semantics for the "other case" you have i= n mind ?
Denis

Yes, I omitted your comments in that post because I'd previously replied to you in a separate message where I said that the "actor_token is a security token so that's not = an issue that needs to be addressed."=C2=A0 https://www.ietf.org/mail-archive/web/oauth/current/msg17247.ht= ml

The other point you've just made about having very precise semantics for a field is a fair one. However, I wanted to avoid introducing yet another field (or really two fields b/c of the associated *_type for each inbound token field), for what felt like a minor semantic variation that could be easily accommodated by the existing framework, to the draft that already has a lot of options and parameters on the request. And Token Exchange really is a framework. I think that, to some extent, the framework is a bit of a Rorschach test for deployers and implementers to utilize to solve their specific issues and needs. I expect that will be the case regardless. And I am proposing to somewhat genericize the text around one request parameter to be more reflective of that.

I would like to hear from others in the WG though.

On Tue, May 9, 2017 at 3:06 AM, Denis <denis.ietf@free.fr> wrote:
Brian,

You omitted to include my comments in this post. So here it is again:

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

The current text is:

actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token=C2=A0 OPTIONAL.=C2=A0 A security token that represents the identity of the acting party.

The current text states:
Typically, in the request, the subject_token represents the identity of the party on behalf of whom
 the token is being requested while the actor_token represents the identity of the party to whom the access
rights of the issued token are being delegated.
Logically, the definition should be along the following lines:

=C2=A0actor_token OPTIONAL. Indic= ates the identity of the party to whom the access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not be used.

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

I read your argumentation, but I maintain my comment. Each field should have a precise semantics.

If you want to have another semantics, you should propose to define another field with its precise meaning.

Denis

Let me throw out a bit more context about this. The "actor_token" might, in a delegation scenario, represent the identity of the party to whom the access rights of the issued token are being delegated. That's the typical delegation scenario that is discussed in the draft. However, the "actor_token" might als= o be utilized/needed by the AS in an impersonation scenario for policy or auditing reasons even when the resulting issued token doesn't contain info about the delegation or actor. Similarly, the actor might not be strictly doing the impersonation but rather just be a party (again maybe needed for policy or auditing) to the token exchange event itself.=C2=A0 When I wrote the "actor_token" text in section 2.1 some ~18 = months ago I had the delegation scenario at the front of my mind and (clearly) intended to accommodate it. However, I didn't intend to limit it to only that and, looking at the text again, I think what is there now is too prescriptive and narrow. Thus my proposing to generalize the text somewhat.




On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:
I do have one minor issue I'd like to raise that relates to some conversations I've been a party to recently about implementations and applications of token exchange.

I think that the current text in =C2=A72.1 for the "actor_token" is overly spe= cific towards the delegation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text:

=C2=A0=C2=A0 actor_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2= =A0 A security token that represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 acting party.= =C2=A0




On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far.


Authors,

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
=C2=A0Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <b= campbell@pingidentity.com> wrote:
As mentioned during the Chicago meeting the "invalid_target" = error code that was added in -07 was intended to give the AS a standard way to reject request with multiple audiences/resources that it doesn't understand o= r is unwilling or unable to process based on policy or whatever criteria . It was intended as a compromise, of sorts, to allow for the multiple resources/audiences in the request but provide an easy out for the AS of saying it can't be supported based on whatever implementation or security or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@= gmail.com> wrote:
Th= ere are cases where tokens are supposed to be consumed at multiple places and the `aud` needed to capture them. That's why `aud` is a multi-valued field.=C2=A0

= On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael= .Jones@microsoft.com>:

For the same reason that the =E2=80=9Caud= =E2=80=9D claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.=C2=A0 Ditto for resources.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 [mailto:oa= uth-bounces@ietf.org] On Behalf Of Bri= an Campbell
torsten@lod= derstedt.net>
oauth@ietf.org= >
=C2=A0

Thanks for the review and question, Torsten.

The desire to support multiple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.

From an individual perspective, I tend to agree with you that allowing for multiple audiences/resourc= es adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to= give the AS a standard way to deal with the complexity and reject request with multiple audiences/resourc= es that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

=C2=A0

=C2=A0

=C2=A0

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lod= derstedt.net> wrote:

Hi Brian,

=C2=A0

thanks for the clarification around resource, audience and scope.=C2=A0

=C2=A0

Here are my comments on the draft:

=C2=A0

In section 2.1 it states: =E2=80=9EMultiple "resource&qu= ot; parameters may be used to indicate

=C2=A0 =C2=A0 =C2=A0 tha= t the issued token is intended to be used at the multiple

=C2=A0 =C2=A0 =C2=A0 res= ources listed.=E2=80=9C<= /p>

=C2=A0

Can you please explain the rational in more detail? I don=E2=80=99t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction.=C2=A0<= /p>

=C2=A0

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

=C2=A0

And it is getting even more complicated given there could also be multiple audience values and the client could mix them:=C2=A0

=C2=A0

"Multiple "audience&qu= ot; parameters

=C2=A0 =C2=A0 =C2=A0 may= be used to indicate that the issued token is intended to be

=C2=A0 =C2=A0 =C2=A0 use= d at the multiple audiences listed.=C2=A0 The "audience&qu= ot; and

=C2=A0 =C2=A0 =C2=A0 &qu= ot;resource" parameters may be used together to indicate multiple

=C2=A0 =C2=A0 =C2=A0 tar= get services with a mix of logical names and physical

=C2=A0 =C2=A0 =C2=A0 locations.=E2=80= =9C

=C2=A0

And in the end the client may add some scope values to the =E2=80=9Emeal=E2= =80=9C, which brings us to=C2= =A0

=C2=A0

=E2=80=9EEffec= tively, the requested access rights of the

=C2=A0 =C2=A0token are t= he cartesian product of all the scopes at all the target

=C2=A0 =C2=A0services.&q= uot;

=C2=A0

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

=C2=A0

kind regards,

Torsten.

=C2=A0

=C2=A0

Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbel= l@pingidentity.com>:

=C2=A0

Draft -07 of "OAuth 2.0 Token E= xchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource= /scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

=C2=A0=C2=A0 -07<= br class=3D"m_1633664759536086206m_-8610107656712704476gmail-m_-68532656549= 03375744m_-5500081355606695985m_8684407748554078058m_6905276776273010841m_4= 803735329627533709m_-2675142197049852080m_3983298834558915277m_-43541846352= 20679769gmail_msg">
=C2=A0=C2=A0 o=C2= =A0 Fixed typo (desecration -> discretion).
=C2=A0=C2=A0 o=C2= =A0 Added an explanation of the relationship between scope, audience
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and resource in the request and added an "invalid_tar= get" error
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 code enabling the AS to tell the client that the requested
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 audiences/resourc= es were too broad.

---------- Forwarded message ----------
From: <inte= rnet-drafts@ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-= token-exchange-07.txt
To: i-d-announce@= ietf.org
Cc: oauth@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: OAuth 2.0 Token Exchange =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Authors=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: Michael B= . Jones
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Brian Campbell =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Chuck Mortimore
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Filename=C2=A0 = =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-= token-exchange-07.txt
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 31

<= /div>
...

[Message clipped]=C2= =A0=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1143e26219b6730550ff0a77-- From nobody Fri Jun 2 17:30:30 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2FD12EADB for ; Fri, 2 Jun 2017 17:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZD8yAe1T-CU for ; Fri, 2 Jun 2017 17:30:20 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 BEC5112EAA6 for ; Fri, 2 Jun 2017 17:30:18 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m47so21290628iti.1 for ; Fri, 02 Jun 2017 17:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fOllomGy/TXSq8XTo5bQ+OxdAZ179x0LdNIuSQil8c4=; b=amuVfa3dxVTX77ccxzJlCbVsexOj46JFjSQlIOkHQKYV53nWma40JNajrNcEUX1mCb NohlCmSEsS1LMT7kFZNWHYDVM2kKoUlwtoyAuLTsp1mSQl18LVCJfOXxDjVd6U3LG5UE 7dIDzuQjDOvH5t9oiRqvyG9d489zKc3Q7HPVnMwQp2RC4Jn4G7uO0xoOok/EWFViEDvq VsZOqs8JP/U3pIldBj319PAHhHUYF4spdEZWkNLPDHDn+O8Oyjv/j2MMfydJAxC/jRAA 722BBOG9Z2GJ8sWNn9I1uBQanvG1zXGbPrFLLjfrL0G8btloARuyqHpUz53L25faMYEY ALOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fOllomGy/TXSq8XTo5bQ+OxdAZ179x0LdNIuSQil8c4=; b=YkQVTshObWre5vcybyxJCMLZZdR6jU9DQSHLL0wfx273pxdURxpCUpd1+PqEV7ZelT 11QBnlqNJKbCfnXQDD67mQ63PcMcG6cQgVQ0v4OiT3/uzw1TEA1aUDRo1BsEm1vShWfv zjCjncmy8ttDiD/jxMYOIIsaXXFmjgrqPRiULL3lny77qBYs+6IVJWwHpMzsF1hA2nHN GdZK3HmbkusTChdBCMfBmiIJARwyCDT1x7rqVgbxKEZA7OlxwAo/oHA49DjZT3tQy6hY 0fNDRE/4YvllooDLmZkGyIXdPA5awi5yhbovOvEqoiaBsqXwvaXFSVNLxF0HOwD96WFA vdzg== X-Gm-Message-State: AODbwcDGyML82fKmJF2FXRndNz2uPihmAm/rS2Dwy95nJKe4Yt3yqAoe Qn7MKBgxKds35aBRANTsVbU5B52GMj8U X-Received: by 10.36.16.211 with SMTP id 202mr2146363ity.2.1496449817818; Fri, 02 Jun 2017 17:30:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.37 with HTTP; Fri, 2 Jun 2017 17:29:57 -0700 (PDT) In-Reply-To: <149559553461.28492.8246838477291927765.idtracker@ietfa.amsl.com> References: <149559553461.28492.8246838477291927765.idtracker@ietfa.amsl.com> From: William Denniss Date: Fri, 2 Jun 2017 17:29:57 -0700 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a1144b174d147170551035f12" Archived-At: Subject: Re: [OAUTH-WG] Eric Rescorla's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 00:30:22 -0000 --001a1144b174d147170551035f12 Content-Type: text/plain; charset="UTF-8" Thank you for your review. Changes to address your comments are staged for v12. Replies inline: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Document: draft-ietf-oauth-native-apps-11.txt > > S 7. > To fully support this best practice, authorization servers MUST > support the following three redirect URI options. Native apps MAY > use whichever redirect option suits their needs best, taking into > account platform specific implementation details. > > It's not entirely clear from this text what "support" means. Would > just echoing whatever redirect URI the client provided count as > support? One way to implement client registration on the server is to have a public/public client type field, and an arbituary list of redirect URIs. So more or less, yes, you can support it by echoing whatever redirect the client registered. There are some specifics involved though, like the loopback type needs to support a wildcard port for example. In practice, many authorization servers place restrictions on the types of URIs that can be registered for different platforms (for example, Google and Microsoft both do this). I've also seen arbitrary restrictions in OSS servers that limited the ability to use with native apps, so I felt it was worth explicitly calling out. There are also different security implications of each redirect URI type. I've revised the text to: To fully support this best practice, authorization servers MUST offer at least the following three redirect URI options to native apps. Native apps MAY use whichever redirect option suits their needs best, taking into account platform specific implementation details. S 7.2. > > App-claimed HTTPS redirect URIs have some advantages in that the > identity of the destination app is guaranteed by the operating > system. For this reason, they SHOULD be used in preference to the > other redirect options for native apps where possible. > > You should probably be clearer on who this guarantee is provided to. > I've updated the text. The guarantee is to the authorization server that performed the redirect. > And I assume this SHOULD is directed to app authors? > Yes, updated. > > Claimed HTTPS redirect URIs function as normal HTTPS redirects from > the perspective of the authorization server, though as stated in > Section 8.4, it is REQUIRED that the authorization server is able to > distinguish between public native app clients that use app-claimed > HTTPS redirect URIs and confidential web clients. > > S 8.4 doesn't seem clear on how one makes this distinction. Is > it just a matter of remembering what the app author told you? > I reworked this section to make the point that the HTTPS URIs are indistinguishable so you'll need to use the client type from registration to distinguish. > > > S 8.1. > As most forms of inter-app URI-based communication send data over > insecure local channels, eavesdropping and interception of the > authorization response is a risk for native apps. App-claimed HTTPS > redirects are hardened against this type of attack due to the > presence of the URI authority, but they are still public clients and > the URI is still transmitted over local channels with unknown > security properties. > > I'm probably missing something, but I'm not sure what this last > sentence means. Is the channel here the one that kicks off the > native app with the HTTPS URI as the target? > Yes. I re-worked this section so it flows a bit better and has less duplication, hopefully I resolved this ambiguity. --001a1144b174d147170551035f12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your review. Changes to address your comments are stag= ed for v12.

Replies inline:
=C2=A0
-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Document: draft-ietf-oauth-native-apps-11.txt

S 7.
=C2=A0 =C2=A0To fully support this best practice, authorization servers MUS= T
=C2=A0 =C2=A0support the following three redirect URI options.=C2=A0 Native= apps MAY
=C2=A0 =C2=A0use whichever redirect option suits their needs best, taking i= nto
=C2=A0 =C2=A0account platform specific implementation details.

It's not entirely clear from this text what "support" means. = Would
just echoing whatever redirect URI the client provided count as
support?

One way to implement client regist= ration on the server is to have a public/public client type field, and an a= rbituary list of redirect URIs. So more or less, yes, you can support it by= echoing whatever redirect the client registered. There are some specifics = involved though, like the loopback type needs to support a wildcard port fo= r example.

In practice, many authorization servers= place restrictions on the types of URIs that can be registered for differe= nt platforms (for example, Google and Microsoft both do this). I've als= o seen arbitrary restrictions in OSS servers that limited the ability to us= e with native apps, so I felt it was worth explicitly calling out. There ar= e also different security implications of each redirect URI type.

I've revised the text to:

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 To fully support this best practice, = authorization servers MUST offer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 at l= east the following three redirect URI options to native apps. Native
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 apps MAY use whichever redirect option suit= s their needs best, taking
=C2=A0 =C2=A0 =C2=A0 =C2=A0 into accou= nt platform specific implementation details.

S 7.2.

=C2=A0 =C2=A0App-claimed HTTPS redirect URIs have some advantages in that t= he
=C2=A0 =C2=A0identity of the destination app is guaranteed by the operating=
=C2=A0 =C2=A0system.=C2=A0 For this reason, they SHOULD be used in preferen= ce to the
=C2=A0 =C2=A0other redirect options for native apps where possible.

You should probably be clearer on who this guarantee is provided to.

I've updated the text. The guarantee is t= o the authorization server that performed the redirect.
=C2=A0
And I assume this SHOULD is directed to app authors?
<= br>
Yes, updated.
=C2=A0

=C2=A0 =C2=A0Claimed HTTPS redirect URIs function as normal HTTPS redirects= from
=C2=A0 =C2=A0the perspective of the authorization server, though as stated = in
=C2=A0 =C2=A0Section 8.4, it is REQUIRED that the authorization server is a= ble to
=C2=A0 =C2=A0distinguish between public native app clients that use app-cla= imed
=C2=A0 =C2=A0HTTPS redirect URIs and confidential web clients.

S 8.4 doesn't seem clear on how one makes this distinction. Is
it just a matter of remembering what the app author told you?

I reworked this section to make the point that the H= TTPS URIs are indistinguishable so you'll need to use the client type f= rom registration to distinguish.
=C2=A0


S 8.1.
=C2=A0 =C2=A0As most forms of inter-app URI-based communication send data o= ver
=C2=A0 =C2=A0insecure local channels, eavesdropping and interception of the=
=C2=A0 =C2=A0authorization response is a risk for native apps.=C2=A0 App-cl= aimed HTTPS
=C2=A0 =C2=A0redirects are hardened against this type of attack due to the<= br> =C2=A0 =C2=A0presence of the URI authority, but they are still public clien= ts and
=C2=A0 =C2=A0the URI is still transmitted over local channels with unknown<= br> =C2=A0 =C2=A0security properties.

I'm probably missing something, but I'm not sure what this last
sentence means. Is the channel here the one that kicks off the
native app with the HTTPS URI as the target?

Yes.

I re-worked this section so it flows a = bit better and has less duplication, hopefully I resolved this ambiguity.

--001a1144b174d147170551035f12-- From nobody Fri Jun 2 17:43:33 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EC812420B for ; Fri, 2 Jun 2017 17:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3Ds-0zmhJgh for ; Fri, 2 Jun 2017 17:43:30 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 5E131129AA3 for ; Fri, 2 Jun 2017 17:43:25 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id m47so33665095iti.0 for ; Fri, 02 Jun 2017 17:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oTSwHtiPGO8QfH1o5Ts5+CuX+MrH/myBFBFLFK2rZso=; b=FuCor2U6aeart/XXRZVxx/MGyYaGp0+EQtTNLu+cJFMroIEiO9j35FLkpfgp7akFhL UzyrtSgNMx6vMWupIrnAzaT1CmYjO1P4IRsovch/iYbCmiCbE0mF1BH2+zaQZKcGnLlj o61tYM8ZDdgbv66ynJCk0YfStJGKhE5+SivMI5SakCisCRvupZRP76inJx4BKwNjrY+S aSWLABRMgnSnOGKTvPEzIDqmwQABnZfgUrP/jsHSI851K2g863eqxm9Qpn5unLvWXuVz tRE2bJAi3L+2/+nVjQxm8ueudaC2DBDGrx+1n4goqsYSRA9Paqg2sPQv8NQ1gFV+z/Rr PO+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oTSwHtiPGO8QfH1o5Ts5+CuX+MrH/myBFBFLFK2rZso=; b=Gg7QaI903gcgPAO6GC7jY4yPcK9dEaGykMJsNWyG9FfNT1HnmJkzUSCgkuMspRWIHE 4a0u6sHvhJJz2zyiGEVTKEmiiqmjNozAu8wF8i820plX5jx8K7ZToOhewg+UO6pQZfEf N3QmWk+tBEqWQbUvhG81mXf6zJJ9S+fBFobiUSngHWqPqmztO3Mo2xEdO6uw4QRFqFcD /Q0kpn6SlKC+YGeXC2O73w/PLPYchLCsdqJvX2KIbncWfbJmgIqBxjVsdon1aCwhNyH3 Wb3Bf+d2T/2lQYONn0XQ/QfDSjVNJB5EA53SytQNOs/StazzSXQ6mYh4N+T4KvjZlfH1 cbhA== X-Gm-Message-State: AODbwcAhfWkL/nV3AFQ8iuHtG63DLbmrMljUdOXpyKnQpmesHziVKKOk nG1oF6O6sLRxA+z5wapLng4eUrl++Lt1 X-Received: by 10.107.134.91 with SMTP id i88mr5785088iod.53.1496450604282; Fri, 02 Jun 2017 17:43:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.37 with HTTP; Fri, 2 Jun 2017 17:43:03 -0700 (PDT) In-Reply-To: References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> <1D2FDD6E-3DA0-4E7C-BBF3-1A6146F7889B@fastmail.fm> <1495534158.1405045.985657536.26AE401D@webmail.messagingengine.com> From: William Denniss Date: Fri, 2 Jun 2017 17:43:03 -0700 Message-ID: To: Adam Roach Cc: Alexey Melnikov , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , "oauth@ietf.org" , The IESG , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113ecd98b1b1c90551038eff" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 00:43:32 -0000 --001a113ecd98b1b1c90551038eff Content-Type: text/plain; charset="UTF-8" On Tue, May 23, 2017 at 9:53 AM, Adam Roach wrote: > On 5/23/17 05:09, Alexey Melnikov wrote: > > On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote: > > Hi William, > > On 22 May 2017, at 23:14, William Denniss wrote: > > Section 8.1 makes the statement that "Loopback IP based redirect URIs may > be susceptible to interception by other apps listening on the same > loopback interface." That's not how TCP listener sockets work: for any > given IP address, they guarantee single-process access to a port at any > one time. (Exceptions would include processes with root access, but an > attacking process with that level of access is going to be impossible to > defend against). While mostly harmless, the statement appears to be false > on its face, and should be removed or clarified. > > > Will be removed in the next update. Thank you. > > > Actually, I disagree with Adam on this, because what he says is OS > specific. So I think the text is valuable and should stay. > > In particular, I think SO_REUSEADDR socket option is widely implemented, > both on Windows and Linux. > > > Okay, after doing a lot of digging, this appears to be much more > complicated than it should be [1]. Linux (as of 3.9) does allow multiple > _listeners_ on a single IP/Address pair (and does load balancing among them > o_O), but only if they're both using SO_REUSEADDR ("don't do that then" > would be good advice). Windows allows the kind of hijacking described in > the document unless SO_EXCLUSIVEADDRUSE is set (and it might be good advice > in this document to suggest setting it). > Thank you Alexey and Adam for the discussion and research! I've added notes to both the Windows and Linux implementation details (staged for v12). > So I'm okay with the paragraph staying in, although I would like to see it > qualified with "on some operating systems", and would like to see a note > (probably in section B.3) recommending the use of SO_EXCLUSIVEADDRUSE on > listening sockets. > Added the qualifier "on some operating systems" for the next version. /a > > > ____ > > [1] The most comprehensive explanation of facts on the ground that I could > find is https://stackoverflow.com/questions/14388706/socket- > options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t > --001a113ecd98b1b1c90551038eff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 23, 2017 at 9:53 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 5/23/17 05= :09, Alexey Melnikov wrote:
=20
On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote:
Hi William,

On 22 May 2017, at 23:14, William Denniss <wdenniss@google.com> wrote:
Section 8.1 makes the statement that "Loopback IP bas= ed redirect URIs may
be susceptible to interception by other apps listening on the same
loopback interface." That's not how TCP listener sockets work: for any
given IP address, they guarantee single-process access to a port at any
one time. (Exceptions would include processes with root access, but an
attacking process with that level of access is going to be impossible to
defend against). While mostly harmless, the statement appears to be false
on its face, and should be removed or clarified.


Will be removed in the next update. Thank you.

Actually, I disagree with Adam on this, because what he says is OS specific. So I think the text is valuable and should stay.

In particular, I think SO_REUSEADDR socket option is widely implemented, both on Windows and Linux.


Okay, after doing a lot of digging, this appears to be m= uch more complicated than it should be [1]. Linux (as of 3.9) does allow multiple _listeners_ on a single IP/Address pair (and does load balancing among them o_O), but only if they're both using SO_REUSEADDR ("don't do that then" would be good advice= ). Windows allows the kind of hijacking described in the document unless SO_EXCLUSIVEADDRUSE is set (and it might be good advice in this document to suggest setting it).


Thank you Alexey and Adam for the discussion and research!
=

I've added notes to both the Windows and Linu= x implementation details (staged for v12).=C2=A0
=C2=A0
=

So I'm okay with the paragraph staying in, although I would like to see it qualified with "on some operating systems", and w= ould like to see a note (probably in section B.3) recommending the use of SO_EXCLUSIVEADDRUSE on listening sockets.


Added the qualifier "on some operating systems"= for the next version.

/a


____

[1] The most comprehensive explanation of facts on the ground that I could find is https://stac= koverflow.com/questions/14388706/socket-options-so-reuseaddr-and-= so-reuseport-how-do-they-differ-do-they-mean-t


--001a113ecd98b1b1c90551038eff-- From nobody Fri Jun 2 19:26:10 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87461129B91 for ; Fri, 2 Jun 2017 19:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNhXVCGzF12F for ; Fri, 2 Jun 2017 19:26:06 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 1222C1294A2 for ; Fri, 2 Jun 2017 19:26:06 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id m47so7312843iti.1 for ; Fri, 02 Jun 2017 19:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R5MFLE8bL5SLXrwD8Mn/AlwFiI/lEaa5LFMrs3pt96c=; b=ogeiwB8snmyKsnnMxGLm35+elZAU7AQwZs1TKIt7FiN946+UbAVmCUjPgs4Ef58Dru L0FReWEsHKP76embnMJO3Q4KhxTshKa0MuuDxk8DLZLLtt78SzsD1WYD6R8MUNTi5fAZ cVS34ZoYfOdGEYWhi59Axfochqer9Qx2Zx8VkmNa6J9t7hJjhu4crEn++aOFeB9pLfXZ GX5CJoiO1Tktz+bGJR4Ka3rFPJ65C4PsF/LKzKiGHnTOdyp42/hVLeJcRftgaOFXo6r/ 77+AF6qd5XS+Zcbo80hjRDtDAG/axgwWhFV6iQbzRV2VDdFpe3swwccnWLxKd5xjkYXf qLAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R5MFLE8bL5SLXrwD8Mn/AlwFiI/lEaa5LFMrs3pt96c=; b=r1g7rO16DboIprqIOy5ayv6Wv/0uS3Fc4Cx/sXaFU5l6uj2UOZRf/2JyQFLwNrzyYx D8Rza1s5r081gzW2DAujV7j0cdqmaU3WMahwjpMyNhSTAhjQg1ErwpBL+3H7aQLtRtoM 4HkZqEdS4Ujh4eKCZ3PGh8VT7x+ZNOh2eu0DjFKRXUkEyUQPxNkIThug+drceyiheSYi p6l/zr78YjT6flhQU4XCIxhmPdQLROtalOc6cWuV7a+LJMeHhtmTm3yzOPMcIMMhKzcx +7DR5oO/9uzeHypSDJpUz7bPLNFnayq2x5SupjOkCyy1WvR4ZW2F21xCUj6MM0y04BrG jy4w== X-Gm-Message-State: AODbwcCJuKfH5yxdvFS1FqW73KepEGhALIKAMpcuVPWqwymPWVySfMw4 +WzhwxvYCNV79jvUyaUW/LjQ6et34Yix X-Received: by 10.107.25.203 with SMTP id 194mr10724104ioz.182.1496456765123; Fri, 02 Jun 2017 19:26:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.37 with HTTP; Fri, 2 Jun 2017 19:25:44 -0700 (PDT) In-Reply-To: References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> From: William Denniss Date: Fri, 2 Jun 2017 19:25:44 -0700 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a113fe2dae8b2fb055104fda8" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 02:26:09 -0000 --001a113fe2dae8b2fb055104fda8 Content-Type: text/plain; charset="UTF-8" On Tue, May 23, 2017 at 10:27 AM, Adam Roach wrote: > William -- > > Thanks for your quick responses! I have only one follow-up (beyond my > response to the thread that Alexey started): > > On 5/22/17 17:14, William Denniss wrote: > > My understanding of the Web Authentication Broker is that it is > effectively a special-case browser designed for authentication. There is a > single cookie-jar which is retained and used with all apps that use the Web > Authentication Broker in "SSO mode". So logins are shared, and the > advantages of Section 4 apply. It's a separate cookie-jar from the main > browser, which would imply a minimum of two sign-ins on the device (so not > quite "single" at a device level), but I'm not sure if this is enough to > disqualify it. > > My goal here is to simply document the current state of the art of the > platforms, and I felt that the Web Authentication Broker qualified as an > external user agent per the BCP. The user interface is arguably quite nice > too, which mitigates some of the downsides of using a special > authentication "browser" with a separate cookie jar. > > > Some of this comes down to user experience and some of it comes down to > user choice. I'm going to speak using first-person pronouns here, but > please be aware that I'm speaking from the point of view of a significant > body of users. > > For the user experience side of things: users of Firefox and Chrome will > commonly take advantage of cross-machine, cross-platform password > synchronization built into those browsers, and the recommendation you're > giving in this document defeats those pretty soundly. Thinking all the way > through the user experience you're promoting, here's what this would look > like to me: > > 1. Native app has a button I can use to [link an account, authenticate > myself, etc] > 2. I click that button, and the Web Authentication Broker opens > 3. I manually open Firefox, go to options->security, and click on > "saved logins" > 4. I type in the name of the authenticating website, click on "Show > Passwords," and enter my master password > 5. I copy and paste the (long, randomly-generated) password for the > authenticating website into the Web Authentication Broker > > That's... pretty friction-laden, especially when you consider that opening > the authentication flow in my native browser would take maybe one or two > clicks instead. The situation for Chrome users is approximately as bad. > > > The other part of this recommendation (and I think this is a bigger issue) > is that I, as a user, have made a pretty conscious decision about the > browser I want to use for these kinds of things, based in part on the way I > know various browsers handle things like analytics and privacy, and based > in part on the speed with which browser security exploits are patched. I'm > going to presume that the Web Authentication Broker acts in every way that > I care about like either Edge or Explorer (probably Edge), which is likely > to fall outside the envelope of what I'm okay with in a browser. I don't > mean this as a major knock on Edge; I just have certain preferences in this > area, and it's a choice that I feel I should be allowed to make and have > respected when possible. > This section is written in a way that reads very much like "use the Web > Authentication Broker when possible, and fall back on the user's explicitly > selected and preferred browser only as a last resort." This circumvents the > user agency I describe above, which gives me more than a little cause for > concern. > > For these two reasons, I would like to see the recommendation in this > section pretty much reversed: calling to to the browser registered with the > operating system should be preferred so as to respect user agency, followed > by a note that using the Microsoft Web Authentication Browser in SSO Mode > qualifies as using an External Browser as described in this document, > although it has the three drawbacks of: > > 1. Not integrating with cookie storage for the user's preferred > browser. > 2. Not integrating with password management for the user's preferred > browser. > 3. Bypassing user choice regarding various browser attributes, such as > privacy and security properties. > > > /a > In my staged copy , I have followed your advice and reversed the recommendation ordering, and mentioned the caveats that the user's personalisations are not present in the broker. The lack of password manager support is a very good point. It's definitely been one of the advantages we've seen by moving to browsers from web-view. --001a113fe2dae8b2fb055104fda8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 23, 2017 at 10:27 AM, Adam Roach <adam@nostrum.com><= /span> wrote:
=20 =20 =20
William --

Thanks for your quick responses! I have only one follow-up (beyond my response to the thread that Alexey started):

On 5/22/17 17:14, William Denniss wrote:
My understanding of the Web Authentication Broker is that it is effectively a special-case browser designed for authentication. There is a single cookie-jar which is retained and used with all apps that use the Web Authentication Broker in "SSO mode= ". So logins are shared, and the advantages of Section 4 apply.=C2=A0 It's a separate cookie-jar from the main bro= wser, which would imply a minimum of two sign-ins on the device (so not quite "single" at a device level), but I= 9;m not sure if this is enough to disqualify it.

My goal here is to simply document the current state of the art of the platforms, and I felt that the Web Authentication Broker qualified as an external user agent per the BCP.=C2=A0 The user interface is arguably qui= te nice too, which mitigates some of the downsides of using a special authentication "browser" with a separat= e cookie jar.

 Some of this comes down to user experience and some of it comes down to user choice. I'm going to speak using first-person pronouns here= , but please be aware that I'm speaking from the point of view of a significant body of users.

For the user experience side of things: users of Firefox and Chrome will commonly take advantage of cross-machine, cross-platform password synchronization built into those browsers, and the recommendation you're giving in this document defeats those pretty soundly. Thinking all the way through the user experience you're promoting, here's what this would look like to me:
  1. Native app has a button I can use to [link an account, authenticate myself, etc]
  2. I click that button, and the Web Authentication Broker opens
  3. I manually open Firefox, go to options->security, and click on "saved logins"
  4. I type in the name of the authenticating website, click on "Show Passwords," and enter my master password
  5. I copy and paste the (long, randomly-generated) password for the authenticating website into the Web Authentication Broker

That's... pretty friction-laden, especially when you consider that opening the authentication flow in my native browser would take maybe one or two clicks instead. The situation for Chrome users is approximately as bad.


The other part of this recommendation (and I think this is a bigger issue) is that I, as a user, have made a pretty conscious decision about the browser I want to use for these kinds of things, based in part on the way I know various browsers handle things like analytics and privacy, and based in part on the speed with which browser security exploits are patched. I'm going to presume that the Web Authentication Broker acts in every way that I care about like either Edge or Explorer (probably Edge), which is likely to fall outside the envelope of what I'm okay with in a browser. I don't mean this as a major knock on Edge; I just have certain preferences in this area, and it's a choice that I feel I should be allowed to make and have respected when possible.

This section is written in a way that reads very much like "use th= e Web Authentication Broker when possible, and fall back on the user'= s explicitly selected and preferred browser only as a last resort." This circumvents the user agency I describe above, which gives me more than a little cause for concern.

For these two reasons, I would like to see the recommendation in this section pretty much reversed: calling to to the browser registered with the operating system should be preferred so as to respect user agency, followed by a note that using the Microsoft Web Authentication Browser in SSO Mode qualifies as using an External Browser as described in this document, although it has the three drawbacks of:
  1. Not integrating with cookie storage for the user's preferred browser.
  2. Not integrating with password management for the user's preferred browser.
  3. Bypassing user choice regarding various browser attributes, such as privacy and security properties.

/a

In my staged copy, I have followed your advice and reversed= the recommendation ordering, and mentioned the caveats that the user's= personalisations are not present in the broker. The lack of password manag= er support is a very good point. It's definitely been one of the advant= ages we've seen by moving to browsers from web-view.


--001a113fe2dae8b2fb055104fda8-- From nobody Fri Jun 2 20:01:43 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5011712EBA5; Fri, 2 Jun 2017 20:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T8IQRJ8YWke; Fri, 2 Jun 2017 20:01:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375CB12EBA4; Fri, 2 Jun 2017 20:01:35 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5331QuY006494 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 2 Jun 2017 22:01:27 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: William Denniss Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, "oauth@ietf.org" References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <6823ceb2-03cc-606a-1841-5924840389d4@nostrum.com> Date: Fri, 2 Jun 2017 22:01:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3D012462F2F282AE4CE4B53A" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 03:01:36 -0000 This is a multi-part message in MIME format. --------------3D012462F2F282AE4CE4B53A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/2/17 21:25, William Denniss wrote: > In my staged copy > , > I have followed your advice and reversed the recommendation ordering, > and mentioned the caveats that the user's personalisations are not > present in the broker. The lack of password manager support is a very > good point. It's definitely been one of the advantages we've seen by > moving to browsers from web-view. Thanks! The new text in the Windows section looks great. /a --------------3D012462F2F282AE4CE4B53A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 6/2/17 21:25, William Denniss wrote:
In my staged copy, I have followed your advice and reversed the recommendation ordering, and mentioned the caveats that the user's personalisations are not present in the broker. The lack of password manager support is a very good point. It's definitely been one of the advantages we've seen by moving to browsers from web-view.

Thanks! The new text in the Windows section looks great.

/a
--------------3D012462F2F282AE4CE4B53A-- From nobody Sun Jun 4 06:12:46 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0990129469 for ; Sun, 4 Jun 2017 06:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA_EtSBqZNn9 for ; Sun, 4 Jun 2017 06:12:42 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0111.outbound.protection.outlook.com [104.47.37.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89DF129B29 for ; Sun, 4 Jun 2017 06:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sjTZMSXArsBBH86gWOe+PfUn+NggZxKjcbtxqwpof5c=; b=DSWzzFZBgLIU9qI4Qmvj/WGUkPC6Oo2pXn0kVLDsfsrRYKc+R7wNWf/H07f5Nl7fwu2Bi6fSD2CrBamlRDK6ZcByO7g10SUbWtJkNQO5xe7jo0QjchhBgDBKsyF7zhIoD5lEbWZlpULCh/RpONFuy7R89YNux6GEjX+pefIgQBI= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0471.namprd21.prod.outlook.com (10.172.121.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.0; Sun, 4 Jun 2017 13:12:39 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1178.000; Sun, 4 Jun 2017 13:12:38 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Initial JSON Web Token Best Current Practices Draft Thread-Index: AdLdLiuU8v8bzUlIS+Ocr4mmEw/lEA== Date: Sun, 4 Jun 2017 13:12:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-04T06:12:36.1315142-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0471; 7:Uk2tYyKa9aDaYTtVyrlvRW6zIvdbL4SpS8EOWxaZpDB9tZZBZGqF2rBltthM7tSgZL0xm9ZBkalVEX8vUn8NBbBkrKEd7Z4P1lCyvta6C8LasodIx3NXxWJKaTzksKpqEnELWRE9rXwWT5n3rEwro0pRW8boSv1EuoPuksHYhpqVsvqiFJfRfEl8GwCWb4mywIvvCq5PzC2/BIpc5f2HmRDgVP59MZM4kaMJcmUrnykVWQBDFQNhtoRmoaxLaxFXb+kGGGLVKjy6Si3Dx+mp1pdhk1JELJFFYdFQMOdcbK9kYPyh7ZxR/l1Ee9pwH/TPLLI3dHTiBjW4/0N1IzRJ6okArB0DEopSSCsnemrkyHY= x-ms-office365-filtering-correlation-id: 3b471776-f1f4-42ae-8c8a-08d4ab4b601d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR21MB0471; x-ms-traffictypediagnostic: CY4PR21MB0471: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(278428928389397)(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0471; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0471; x-forefront-prvs: 03283976A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(209900001)(2501003)(14454004)(5005710100001)(72206003)(5660300001)(74316002)(7736002)(7906003)(790700001)(25786009)(478600001)(10090500001)(10290500003)(53376002)(86362001)(3280700002)(66066001)(6916009)(2906002)(86612001)(7696004)(966005)(8990500004)(38730400002)(110136004)(556974002)(8676002)(81166006)(1730700003)(3660700001)(6506006)(33656002)(8936002)(77096006)(122556002)(54356999)(5640700003)(606005)(2351001)(3846002)(102836003)(50986999)(6436002)(99286003)(55016002)(6306002)(9686003)(54896002)(236005)(5630700001)(2900100001)(53936002)(189998001)(6116002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0471; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504E898E2414522D172663BF5F50CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2017 13:12:38.6486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0471 Archived-At: Subject: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:12:45 -0000 --_000_CY4PR21MB0504E898E2414522D172663BF5F50CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) fu= nctions underlying them are now being widely used in diverse sets of applic= ations. During IETF 98 in Chicago, we discus= sed reports of people implementing and using JOSE and JWTs insecurely, the = causes of these problems, and ways to address them. Part of this discussio= n was an invited JOSE/JWT Security Update presentation th= at I gave to two working groups, which included links to problem reports an= d describes mitigations. Citing the widespread use of JWTs in new IETF app= lications, Security Area Director Kathleen Moriarty suggested during these = discussions that a Best Current Practices (BCP) document be written for JSO= N Web Tokens (JWTs). I'm happy to report that Yaron Sheffer, Dick Hardt, and myself have produce= d an initial draft of a JWT BCP. Its abstract is: JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-based security tokens that contain a set of clai= ms that can be signed and/or encrypted. JWTs are being widely used and depl= oyed as a simple security token format in numerous protocols and applicatio= ns, both in the area of digital identity, and in other application areas. T= he goal of this Best Current Practices document is to provide actionable gu= idance leading to secure implementation and deployment of JWTs. In Section 2, we describe threats and vulnerabilities. In Section 3, we de= scribe best practices addressing those threats and vulnerabilities. We bel= ieve that the best practices in Sections 3.1 through 3.8 are ready to apply= today. Section 3.9 (Use Mutually Exclusive Validation Rules for Different= Kinds of JWTs) describes several possible best practices on that topic to = serve as a starting point for a discussion on which of them we want to reco= mmend under what circumstances. We invite input from the OAuth Working Group and other interested parties o= n what best practices for JSON Web Tokens and the JOSE functions underlying= them should be. We look forward to hearing your thoughts and working on t= his specification together. The specification is available at: * https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1690 and a= s @selfissued. --_000_CY4PR21MB0504E898E2414522D172663BF5F50CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JSON Web Tokens (JWTs) and the JSON Object Signing a= nd Encryption (JOSE) functions underlying them are now being widely used in= diverse sets of applications.  During IETF 98 in Chicago, we discuss= ed reports of people implementing and using JOSE and JWTs insecurely, the c= auses of these problems, and ways to address them.  Part of this discu= ssion was an invited JOSE/JWT Security Update presentation that I gave to two working groups= , which included links to problem reports and describes mitigations.  = Citing the widespread use of JWTs in new IETF applications, Security Area D= irector Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written = for JSON Web Tokens (JWTs).

 

I’m happy to report that Yaron Sheffer, Dick H= ardt, and myself have produced an initial draft of a JWT BCP.  Its abs= tract is:

JSON Web Tokens, also kno= wn as JWTs [RFC7519], a= re URL-safe JSON-based security tokens that contain a set of claims that ca= n be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numero= us protocols and applications, both in the area of digital identity, and in= other application areas. The goal of this Best Current Practices document = is to provide actionable guidance leading to secure implementation and deployment of JWTs.

 

In Section 2, we describe threats and vulnerabilitie= s.  In Section 3, we describe best practices addressing those threats = and vulnerabilities.  We believe that the best practices in Sections 3= .1 through 3.8 are ready to apply today.  Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) = describes several possible best practices on that topic to serve as a start= ing point for a discussion on which of them we want to recommend under what= circumstances.

 

We invite input from the OAuth Working Group and oth= er interested parties on what best practices for JSON Web Tokens and the JO= SE functions underlying them should be.  We look forward to hearing yo= ur thoughts and working on this specification together.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;             =             &nb= sp;            =         -- Mike

 

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

--_000_CY4PR21MB0504E898E2414522D172663BF5F50CY4PR21MB0504namp_-- From nobody Sun Jun 4 07:11:40 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E56129505 for ; Sun, 4 Jun 2017 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7_tMEkqeOU9 for ; Sun, 4 Jun 2017 07:11:36 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 904C712704B for ; Sun, 4 Jun 2017 07:11:35 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id d73so6458919wma.0 for ; Sun, 04 Jun 2017 07:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BSTRq1WvWU6dVa5FqWjVrHC+CTTA7VWsZLih/YEdeaU=; b=EcTlDyb1gxHHLllU8MWyZ3LFzArxWiW4O9ylET9hQ1h/8047EmOWvfjB5KBmnpmRyd 9Sf+JvtkGq8yhHhdWjQ49WbiLYNSr61Psp1JEy5BkJ8FLYFSpBRSP7SYZQzD0s0PMNrF +TVpB9tlhb4OtNQ7uidYc7Ja3CwwtD822OHVQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BSTRq1WvWU6dVa5FqWjVrHC+CTTA7VWsZLih/YEdeaU=; b=UJjftNxPDRMZAvLENeUu8c8I4qPlY4HBQgNOjugY6c83mDmAb1qK5dyxz/OvbZLn70 YrEKTuItFAcmb14wBAlfdbDRArUGLknewdI4xUBaKwGG14sWwKZxI8tbMNf8z1Px0RYx hAthUKdPos+FYmmsuN7Eh5c4fYBxxH2ywhiWGhTEqd0OPo5g0qm3XQvzlcywOKRUr623 /swzDLmwKhMhwT/92/p3IHjFUO7L86/Hpjsk0RF+UUPhHz2EK4mM1VZt63+apk9tz6AE Y8BbkD+5K0D0OCP+e2uAIwi/LXrRcA3trl3s1xyCho+sqiwU0XDnnAt8kTkNc1Odi88Q 2IBw== X-Gm-Message-State: AODbwcCMXJzwQZMPN2WmzCqc9GhKDAPDV8JZj3ZvfECeiNDJrEMswwKv 6dIUTYKTWh0sAGAN9gY1sLpKXkpYUQ4aLEQjg1lOqmUDQXApUZcNEFtdrlmwajIRwOW22InvCp0 iVPsnrEnLdcmycdrPxX/mhoR+vXH556wjH8D7pgQrhn+VLfhplz/yyg== X-Received: by 10.28.0.13 with SMTP id 13mr5014898wma.19.1496585493654; Sun, 04 Jun 2017 07:11:33 -0700 (PDT) Received: from [192.168.1.2] (37.59.99.195.dyn.plus.net. [195.99.59.37]) by smtp.gmail.com with ESMTPSA id n49sm8719873wrn.30.2017.06.04.07.11.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 07:11:32 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-92E41BD3-AF70-4ED0-AFBC-CF5E0D1B9B85 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Sun, 4 Jun 2017 15:11:31 +0100 Cc: "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: Mike Jones Archived-At: Subject: Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 14:11:40 -0000 --Apple-Mail-92E41BD3-AF70-4ED0-AFBC-CF5E0D1B9B85 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I originally set this message just to the BCP authors. As requested by Mike J= ones, I am sending it here too: Hi, I've just seen this draft best-practice guide for JWTs pop up. I have a numb= er of suggestions for improvements. Mostly, I think the advice is good but s= hould be spelt out a bit more clearly. Here are some suggestions: 1. Explicitly spell out the ECDH-ES public key validation routines from NIST= . I have a blog post summarising them: https://neilmadden.wordpress.com/2017= /05/17/so-how-do-you-validate-nist-ecdh-public-keys/ 2. Recommend that (despite the -ES) ECDH is safest when *both* keys are ephe= meral (eg you use some initial step to retrieve a fresh authenticated epheme= ral key from the other party).=20 3. Spell out how to authenticate ECDH ephemeral keys. For instance, include a= n inner signed JWT that repeats the epk and possibly the apu/apv claims too.= =20 4. Recommend that the apu and apv claims as a bare minimum include a hash of= both public keys and SHOULD include any other known identifiers.=20 5. Recommend that the receiving party recalculates the apu and apv claims fr= om known inputs to check they match. (Or leave these out of the JWT and requ= ire the other party to recalculate them). 6. Provide explicit key lifetime requirements. E.g., for AES GCM this should= not exceed 2^32 messages for randomly-generated IVs, and not exceed 2^64 *b= locks* in total (so unless you restrict JWT lengths to less than 2^32 blocks= and use a message counter as IV then this also limits to 2^32 messages). Fo= r CBC it should not exceed 2^48 messages.=20 7. Require that the "alg" and "enc" claims are ONLY used to reject unexpecte= d algorithms, NEVER to select an algorithm (even amongst a "supported" set).= Cryptographic agility should be achieved by using "kid" claims that referen= ce one of a set of known keys and the key should specify the algorithm (eith= er explicitly or by the key parameters/size).=20 8. Deprecate or strongly recommend against all of the RSA encryption modes e= xcept OAEP-256.=20 9. Strongly discourage any use of compression with encrypted JWEs - it is to= o easy to leak sensitive information.=20 10. Recommend that if a JWE is used to encrypt a password or other value for= which knowing the length may be a weakness, that such fields are explicitly= padded by the application or at least use CBC mode to reduce the amount of l= ength information leaked to a multiple of the AES block size.=20 11. Require constant-time comparisons of HMAC tags.=20 12. Recommend using deterministic ECDSA signatures as described in RFC 6979 t= o minimise the risk of leaking the private key.=20 13. Recommend that if the ECDH calculation produces an all-zero shared secre= t that this is rejected.=20 14. Never produce a signed JWT containing a "sub" claim unless you are expli= citly vouching for the identity of that subject. It is far too easy to accid= entally produce valid OIDC id tokens from unrelated code! Generally I think all of the RSA usage should be deprecated. JWTs are primar= ily used for short tokens and RSA adds too much space overhead there and is f= raught with peril. Elliptic curve crypto is also fraught with peril, but tha= t peril can be managed by explicitly spelling out the validation required an= d using ephemeral keys wherever possible.=20 I hope these comments are useful.=20 Kind regards, Neil Madden Security Director, ForgeRock.=20 > On 4 Jun 2017, at 14:12, Mike Jones wrote: >=20 > JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) f= unctions underlying them are now being widely used in diverse sets of applic= ations. During IETF 98 in Chicago, we discussed reports of people implement= ing and using JOSE and JWTs insecurely, the causes of these problems, and wa= ys to address them. Part of this discussion was an invited JOSE/JWT Securit= y Update presentation that I gave to two working groups, which included link= s to problem reports and describes mitigations. Citing the widespread use o= f JWTs in new IETF applications, Security Area Director Kathleen Moriarty su= ggested during these discussions that a Best Current Practices (BCP) documen= t be written for JSON Web Tokens (JWTs). > =20 > I=E2=80=99m happy to report that Yaron Sheffer, Dick Hardt, and myself hav= e produced an initial draft of a JWT BCP. Its abstract is: > JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-based sec= urity tokens that contain a set of claims that can be signed and/or encrypte= d. JWTs are being widely used and deployed as a simple security token format= in numerous protocols and applications, both in the area of digital identit= y, and in other application areas. The goal of this Best Current Practices d= ocument is to provide actionable guidance leading to secure implementation a= nd deployment of JWTs. > =20 > In Section 2, we describe threats and vulnerabilities. In Section 3, we d= escribe best practices addressing those threats and vulnerabilities. We bel= ieve that the best practices in Sections 3.1 through 3.8 are ready to apply t= oday. Section 3.9 (Use Mutually Exclusive Validation Rules for Different Ki= nds of JWTs) describes several possible best practices on that topic to serv= e as a starting point for a discussion on which of them we want to recommend= under what circumstances. > =20 > We invite input from the OAuth Working Group and other interested parties o= n what best practices for JSON Web Tokens and the JOSE functions underlying t= hem should be. We look forward to hearing your thoughts and working on this= specification together. > =20 > The specification is available at: > https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00 > =20 > An HTML-formatted version is also available at: > http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html > =20 > -- Mike > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1690 and a= s @selfissued. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-92E41BD3-AF70-4ED0-AFBC-CF5E0D1B9B85 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I originally set this messa= ge just to the BCP authors. As requested by Mike Jones, I am sending it here= too:

Hi,

I've just seen this draft best-practice guide for JW= Ts pop up. I have a number of suggestions for improvements. Mostly, I think t= he advice is good but should be spelt out a bit more clearly. Here are some s= uggestions:

1. Explicitly spell out the ECDH-ES public key validation rout= ines from NIST. I have a blog post summarising them: https://neilmadden.wordpress.com/2017/05= /17/so-how-do-you-validate-nist-ecdh-public-keys/
2. Recommend that (desp= ite the -ES) ECDH is safest when *both* keys are ephemeral (eg you use some i= nitial step to retrieve a fresh authenticated ephemeral key from the other p= arty). 
3. Spell out how to authenticate ECDH ephemeral keys. For instan= ce, include an inner signed JWT that repeats the epk and possibly the apu/ap= v claims too. 
4. Recommend that the apu and apv claims as a bare minimu= m include a hash of both public keys and SHOULD include any other known iden= tifiers. 
5. Recommend that the receiving party recalculates the apu and= apv claims from known inputs to check they match. (Or leave these out of th= e JWT and require the other party to recalculate them).
6. Provide explicit k= ey lifetime requirements. E.g., for AES GCM this should not exceed 2^32 mess= ages for randomly-generated IVs, and not exceed 2^64 *blocks* in total (so u= nless you restrict JWT lengths to less than 2^32 blocks and use a message co= unter as IV then this also limits to 2^32 messages). For CBC it should not e= xceed 2^48 messages. 
7. Require that the "alg" and "enc" claims are ONL= Y used to reject unexpected algorithms, NEVER to select an algorithm (even a= mongst a "supported" set). Cryptographic agility should be achieved by using= "kid" claims that reference one of a set of known keys and the key should s= pecify the algorithm (either explicitly or by the key parameters/size). = ;
8. Deprecate or strongly recommend against all of the RSA encryption modes e= xcept OAEP-256. 
9. Strongly discourage any use of compression with encr= ypted JWEs - it is too easy to leak sensitive information. 
10. Recommen= d that if a JWE is used to encrypt a password or other value for which knowi= ng the length may be a weakness, that such fields are explicitly padded by t= he application or at least use CBC mode to reduce the amount of length infor= mation leaked to a multiple of the AES block size. 
11. Require constant= -time comparisons of HMAC tags. 
12. Recommend using deterministic ECDSA= signatures as described in RFC 6979 to minimise the risk of leaking the pri= vate key. 
13. Recommend that if the ECDH calculation produces an all-zer= o shared secret that this is rejected. 
14. Never produce a signed JWT c= ontaining a "sub" claim unless you are explicitly vouching for the identity o= f that subject. It is far too easy to accidentally produce valid OIDC id tok= ens from unrelated code!

Generally I think all of the RSA usage should be= deprecated. JWTs are primarily used for short tokens and RSA adds too much s= pace overhead there and is fraught with peril. Elliptic curve crypto is also= fraught with peril, but that peril can be managed by explicitly spelling ou= t the validation required and using ephemeral keys wherever possible. <= /span>
<= br>
I hope these comments are useful. 

Kind regards,
<= span style=3D"background-color: rgba(255, 255, 255, 0);">
Neil Madden
Secu= rity Director, ForgeRock. 

On 4 Jun 2017, at= 14:12, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

=
=

JSON Web Tokens (JWTs) and the JSON Object Signing an= d Encryption (JOSE) functions underlying them are now being widely used in d= iverse sets of applications.  During IETF 98 in Chicago, we discusse= d reports of people implementing and using JOSE and JWTs insecurely, the cau= ses of these problems, and ways to address them.  Part of this discussi= on was an invited JOSE/JWT Security Update presentation that I gave to two working groups,= which included links to problem reports and describes mitigations.  Ci= ting the widespread use of JWTs in new IETF applications, Security Area Dire= ctor Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written f= or JSON Web Tokens (JWTs).

 

I=E2=80=99m happy to report that Yaron Sheffer, Dick H= ardt, and myself have produced an initial draft of a JWT BCP.  Its abst= ract is:

JSON Web Tokens, also know= n as JWTs [RFC7519], are= URL-safe JSON-based security tokens that contain a set of claims that can b= e signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerou= s protocols and applications, both in the area of digital identity, and in o= ther application areas. The goal of this Best Current Practices document is t= o provide actionable guidance leading to secure implementation and deployment of JWTs.

 

In Section 2, we describe threats and vulnerabilities= .  In Section 3, we describe best practices addressing those threats an= d vulnerabilities.  We believe that the best practices in Sections 3.1 t= hrough 3.8 are ready to apply today.  Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) d= escribes several possible best practices on that topic to serve as a startin= g point for a discussion on which of them we want to recommend under what ci= rcumstances.

 

We invite input from the OAuth Working Group and othe= r interested parties on what best practices for JSON Web Tokens and the JOSE= functions underlying them should be.  We look forward to hearing your t= houghts and working on this specification together.

 

The specification is available at:

 

An HTML-formatted version is also available at:<= /o:p>

 

         = ;             &n= bsp;            =             &nbs= p;       -- Mike

 

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

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-92E41BD3-AF70-4ED0-AFBC-CF5E0D1B9B85-- From nobody Mon Jun 5 04:30:36 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20E5127419 for ; Mon, 5 Jun 2017 04:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj8KzSyVndmk for ; Mon, 5 Jun 2017 04:30:31 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE206129484 for ; Mon, 5 Jun 2017 04:30:30 -0700 (PDT) Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 85F807802C2; Mon, 5 Jun 2017 13:30:28 +0200 (CEST) To: oauth References: From: Denis Message-ID: <858f5a6a-f68c-c616-487a-a64cd8278755@free.fr> Date: Mon, 5 Jun 2017 13:30:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4CFC5F0417437A2D2D0D81EF" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 11:30:35 -0000 This is a multi-part message in MIME format. --------------4CFC5F0417437A2D2D0D81EF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08 1. The abstract states: "This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation". The problem is that the content of the abstract does not match with the content of the document. The abstract clearly states that all cases of token requests are supported, whereas the document mandates the use of a subject_token parameter which restricts the scope to impersonation and delegation. Currently the text states: "subject_token *REQUIRED*. A security token that represents the identity of the party on behalf of whom the request is being made. Typically, the subject of this token will be the subject of the security token issued in response to this request". The abstract should be changed to reflect the content of the document. 2. The text states on page 4: "The scope of this specification is limited to the definition of a basic request and response protocol for an STS-style token exchange utilizing OAuth 2.0. Although a few new JWT claims are defined that enable delegation semantics to be expressed, the specific syntax, semantics and security characteristics of the tokens themselves (both those presented to the AS and those obtained by the client) are explicitly out of scope and no requirements are placed on the trust model in which an implementation might be deployed". These statements are contradictory. One parameter of the request is mandatory (i.e. subject_token) but there is no indication of the kind of treatment which should be done with this parameter so that it will be taken into consideration one way or another in the token that will be issued. This document by itself would be insufficient to allow any kind of interoperability. Conformance to this document would not mean anything. 3. On page 7, the text states: "subject_token REQUIRED. A security token that represents the identity of the party on behalf of whom the request is being made". It is understood that one implementation is already using this parameter to place in it a security token. Since this parameter is indicated as REQUIRED, it is not understandable why a security token shall necessarily be used. There are other means for the STS to identify the "party on behalf of whom the request is being made". Please add a rational. In addition, what the STS will do, can do or should do with this parameter is left undefined. 4. On page 7, the text states: "subject_token REQUIRED. (...) Typically, the subject of this token will be the subject of the security token issued in response to this request". This sentence is quite hard to understand since the specific syntax, semantics and security characteristics of the tokens themselves are explicitly out of scope. The key point is what the STS should do with this parameter: this is left undefined. 5. The text states: " (...) Additional profiles may provide more detailed requirements around the specific nature of the parties and trust involved, such as whether signing and/or encryption of tokens is needed or if proof-of-possession style tokens will be required or issued; Tokens are always signed. Please modify the sentence accordingly. 6. The following sentence is important and is being noticed. The security tokens obtained could be used in a number of contexts, the specifics of which are also beyond the scope of this specification. Changing the "could" into a "may" would however be more appropriate. 7. In section 2.1 request, the text defines: resource OPTIONAL. Indicates the physical location of the target service or resource where the client intends to use the requested security token. and audience OPTIONAL. The logical name of the target service where the client intends to use the requested security token. If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual or entity has accessed which target service and may keep a log of that activity. It would be in a position to act as Big Brother. This should be clearly indicated in a section that is currently missing : "7. Privacy Considerations". See a text proposal hereafter. However, there is indeed the need to restrict the use of tokens to specific targets. The key point is that the target service must be able to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to the target service and that challenge may then be placed into a specific filed of the token. The target service may then verify that the value included in the token is the one that has been recently provided. A parameter specifying the type of the control value and the value of the control should be added. This parameter would be called a target_id (tid). It would solve the Big Brother case. 8. The Security Considerations section states: "In addition, both delegation and impersonation introduce unique security issues. Any time one principal is delegated the rights of another principal, the potential for abuse is a concern. The use of the "scp" claim is suggested to mitigate potential for such abuse, as it restricts the contexts in which the delegated rights can be exercised". Section 4.2 defines the "scp" (Scopes) claim in the following way: The "scp" claim is an array of strings, each of which represents an OAuth scope granted for the issued security token. Each array entry of the claim value is a scope-token, as defined in Section 3.3 of OAuth 2.0 [RFC6749]. Section 3.3 from RFC 6749 defines the Access Token Scope as: "The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. The value of the scope parameter is expressed as a list of space- delimited, case-sensitive strings. The strings are defined by the authorization server". Section 5.4.1 Registry Contents defines scp as: o Claim Name: "scp" o Claim Description: Scope Values o Change Controller: IESG o Specification Document(s): Section 4.2 of [[ this specification ]] Since the "strings are defined by the authorization servers", what a scope may mean is subject to multiple interpretations. The current definition of scp is insufficient to allow any kind of interoperability, now or in the future. It is thus unclear how the use of the "scp" claim might mitigate the risk. 9. This document is currently targeted to become a Standards Track document. RFC 6410 recognizes two maturity levels: - the First Maturity Level: Proposed Standard - the Second Maturity Level: Internet Standard It is not believed that currently it is possible to construct two independent interoperating implementations looking at this document only. Unless more guidance is provided, this document should be targeted to "Experimental". 10. Text proposal for a new section "7. Privacy Considerations". 7. Privacy Considerations 7.1. Resource and audience parameters The use of any these two parameters allow the STS to know which target servers are being accessed by any party making a token request. Any STS is then able to log token requests. This is not a problem if the resource owner and the target server are collocated, but this document is not restricted to that case. For the other cases, it should be noticed that the STS will be in position to act as Big Brother. When privacy is a concern, the use of these parameters is deprecated and the use of a "tid" parameter is recommended. Denis > All, > > We are starting a WGLC on the Token Exchange document: > https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 > > Please, review the document and provide feedback on any issues you see > with the document. > > The WGLC will end in two weeks, on June 17, 2017. > > Regards, > Rifaat and Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------4CFC5F0417437A2D2D0D81EF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08

1. The abstract states:
   "This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation".
The problem is that the content of the abstract does not match with the content of the document.

The abstract clearly states that all cases of token requests are supported, whereas the document mandates
the use of a subject_token parameter which restricts the scope to impersonation and delegation.

Currently the text states:

   "subject_token
      REQUIRED.  A security token that represents the identity of the
      party on behalf of whom the request is being made.  Typically, the
      subject of this token will be the subject of the security token
      issued in response to this request".

The abstract should be changed to reflect the content of the document.


2. The text states on page 4:
   "The scope of this specification is limited to the definition of a
   basic request and response protocol for an STS-style token exchange
   utilizing OAuth 2.0.  Although a few new JWT claims are defined that
   enable delegation semantics to be expressed, the specific syntax,
   semantics and security characteristics of the tokens themselves (both
   those presented to the AS and those obtained by the client) are
   explicitly out of scope and no requirements are placed on the trust
   model in which an implementation might be deployed".
These statements are contradictory. One parameter of the request is mandatory (i.e. subject_token)
but there is no indication of the kind of treatment which should be done with this parameter so that
it will be taken into consideration one way or another in the token that will be issued.

This document by itself would be insufficient to allow any kind of interoperability.
Conformance to this document would not mean anything.


3. On page 7, the text states:

   "subject_token
      REQUIRED.  A security token that represents the identity of the
      party on behalf of whom the request is being made".

It is understood that one implementation is already using this parameter to place in it a security token.
Since this parameter is indicated as REQUIRED, it is not understandable why a security token shall necessarily be used.
There are other means for the STS to identify the "party on behalf of whom the request is being made".

Please add a rational.

In addition, what the STS will do, can do or should do with this parameter is left undefined.


4. On page 7, the text states:

   "subject_token
      REQUIRED.  (...)  Typically, the subject of this token will be
      the subject of the security token issued in response to this
      request".

This sentence is quite hard to understand since the specific syntax, semantics and security characteristics of the tokens themselves
are explicitly out of scope. The key point is what the STS should do with this parameter: this is left undefined.


5. The text states:
   " (...) Additional
   profiles may provide more detailed requirements around the specific
   nature of the parties and trust involved, such as whether signing
   and/or encryption of tokens is needed or if proof-of-possession style
   tokens will be required or issued;
Tokens are always signed. Please modify the sentence accordingly.


6. The following sentence is important and is being noticed.

   The security tokens obtained could be used in a number of contexts,
   the specifics of which are also beyond the scope of this
   specification.

Changing the "could" into a "may" would however be more appropriate.


7. In section  2.1 request, the text defines:

   resource
      OPTIONAL.  Indicates the physical location of the target service
      or resource where the client intends to use the requested security
      token. 

and

   audience
      OPTIONAL.  The logical name of the target service where the client
      intends to use the requested security token. 

If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual
or entity has accessed which target service and may keep a log of that activity. It would be in a position to act as Big Brother.
This should be clearly indicated in a section that is currently missing : "7. Privacy Considerations". See a text proposal hereafter.

However, there is indeed the need to restrict the use of tokens to specific targets. The key point is that the target service
must be able to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to
the target service and that challenge may then be placed into a specific filed of the token. The target service may then verify
that the value included in the token is the one that has been recently provided.

A parameter specifying the type of the control value and the value of the control should be added.
This parameter would be called a target_id (tid). It would solve the Big Brother case.


8. The Security Considerations section states:

   "In addition, both delegation and impersonation introduce unique
   security issues.  Any time one principal is delegated the rights of
   another principal, the potential for abuse is a concern.  The use of
   the "scp" claim is suggested to mitigate potential for such abuse, as
   it restricts the contexts in which the delegated rights can be
   exercised".

Section 4.2 defines the "scp" (Scopes) claim in the following way:

   The "scp" claim is an array of strings, each of which represents an
   OAuth scope granted for the issued security token.  Each array entry
   of the claim value is a scope-token, as defined in Section 3.3 of
   OAuth 2.0 [RFC6749].

Section 3.3 from RFC 6749 defines the Access Token Scope as:

   "The authorization and token endpoints allow the client to specify the
   scope of the access request using the "scope" request parameter.  In
   turn, the authorization server uses the "scope" response parameter to
   inform the client of the scope of the access token issued.
   The value of the scope parameter is expressed as a list of space-
   delimited, case-sensitive strings.  The strings are defined by the
   authorization server".

Section 5.4.1 Registry Contents defines scp as:

   o  Claim Name: "scp"
   o  Claim Description: Scope Values
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.2 of [[ this specification ]]

Since the "strings are defined by the authorization servers", what a scope may mean is subject to multiple interpretations.
The current definition of scp is insufficient to allow any kind of interoperability, now or in the future.

It is thus unclear how the use of the "scp" claim might mitigate the risk.


9. This document is currently targeted to become a Standards Track document.

RFC 6410 recognizes two maturity levels:

   - the First Maturity Level: Proposed Standard
   - the Second Maturity Level: Internet Standard

It is not believed that currently it is possible to construct two independent interoperating implementations
looking at this document only. Unless more guidance is provided, this document should be targeted to "Experimental".


10. Text proposal for a new section "7. Privacy Considerations".

   7. Privacy Considerations

   7.1. Resource and audience parameters

   The use of any these two parameters allow the STS to know which
   target servers are being accessed by any party making a token
   request.  Any STS is then able to log token requests.  This is not
   a problem if the resource owner and the target server are collocated,
   but this document is not restricted to that case.

   For the other cases, it should be noticed that the STS will be in
   position to act as Big Brother.  When privacy is a concern, the use
   of these parameters is deprecated and the use of a "tid" parameter
   is recommended.

Denis

All,

We are starting a WGLC on the Token Exchange document:

Please, review the document and provide feedback on any issues you see with the document.

The WGLC will end in two weeks, on June 17, 2017.

Regards,
 Rifaat and Hannes



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


--------------4CFC5F0417437A2D2D0D81EF-- From nobody Mon Jun 5 04:31:13 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2E12948B for ; Mon, 5 Jun 2017 04:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rJcnH7lVgJm for ; Mon, 5 Jun 2017 04:31:08 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 BDF94127419 for ; Mon, 5 Jun 2017 04:31:07 -0700 (PDT) Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 05490780383; Mon, 5 Jun 2017 13:31:05 +0200 (CEST) To: "oauth@ietf.org" References: From: Denis Message-ID: <178f2f7c-a12e-234d-72aa-9d49d8621489@free.fr> Date: Mon, 5 Jun 2017 13:31:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A3A3A43D55B0EA61E0094038" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 11:31:11 -0000 This is a multi-part message in MIME format. --------------A3A3A43D55B0EA61E0094038 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Comments on draft-sheffer-oauth-jwt-bcp-00 1. Section 2 lists 7 known and possible threats and vulnerabilities with JWT implementations and deployments. In the OAuth Threat Model Document (RFC 6819) collusions between users located inside of a system are not mentioned but nevertheless need to be considered. One threat should be added in this document: Client collusions Text proposal: 2.8 Client collusions RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 identifies security threats coming from hostile parties but does not mention threats coming from collaborating parties. JWTs are issued to a token requestor and are normally intended to be used by that token requestor. They are cases where the forwarding of a JWT to another party is a desirable property so that it can be used by that other party. This is typically the case when a JWT is intended to be used for delegation purposes. However, there are cases where a JWT does not contain a "sub" claim, but other claims that do not allow to identify the token requestor. This is typically the case when a JWT contains an attribute specifying that the token holder is over 18. In such a case, the forwarding of such a JWT to another party would not be a desirable property and should be detected by target servers. Access token binding protection methods currently developed either by the Token Binding WG [Token Binding WG] or by the OAuth WG [OAuth WG] do not allow to counter the forwarding of a JWT legitimately obtained by a party to another party. Either the legitimate party can provide keys to the other party, or if it can't (because private keys are protected by a secure element) it can send requests to his secure element to perform the cryptographic computations that the other party needs. Whatever kind of cryptographic is being used, when two parties are willing to collaborate, a software-only solution will be unable to prevent the transfer of an attribute of a party that possesses it to another party that does not possess it. The use of a secure element will be mandatory. However, the use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be insufficient. Additional functional and security properties will be required for the secure elements. The documents related to OAuth 2.0 do not currently specify how to support secure elements so that the forwarding of a JWT legitimately obtained by a party to another party can be detected by the target server. Unless some extensions are being defined, the OAuth 2.0 framework will be unable to support JWTs containing attributes that do not allow to fully identify the token holder, typically a single attribute specifying that the token holder is over 18. 2. Section 3 lists some best practices. Section 3.8 is written as follows: 3.8. Use and Validate Audience If the same issuer can issue JWTs that are intended for use by more than one relying party or application, the JWT MUST contain an "aud" (audience) claim that can be used to determine whether the JWT is being used by an intended party or was substituted by an attacker at an unintended party. JWTs may be used in a number of contexts, in particular when the resource owner and the target server are not collocated. If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual or entity has accessed which target service and may keep a log of that activity. It would thus be in a position to act as Big Brother. Mandating implementations to have built-in Big Brother properties does not seem to be a "good practice". However, there is indeed the need to restrict the use of JWTs to specific targets. The key point is that the target service must be able to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to the target service and that challenge may then be placed into a specific filed of the JWT. The target service may then verify that the value included in the JWT is the one that has been recently provided. A parameter specifying the type of the control value and the value of the control would need to be used. This parameter would be called a target_id (tid). It would solve the Big Brother case. This parameter cannot be introduced in a BCP document, but this should be done in another document. When the resource owner and the target server are not collocated and when privacy is a concern, the use of these parameters should be deprecated and the use of a "tid" parameter should be recommended. In any case, stating that "the JWT MUST contain an "aud" (audience) claim" is incorrect. Denis > JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption > (JOSE) functions underlying them are now being widely used in diverse > sets of applications. During IETF 98 in Chicago > , we discussed reports of people > implementing and using JOSE and JWTs insecurely, the causes of these > problems, and ways to address them. Part of this discussion was an > invited JOSE/JWT Security Update > > presentation that I gave to two working groups, which included links > to problem reports and describes mitigations. Citing the widespread > use of JWTs in new IETF applications, Security Area Director Kathleen > Moriarty suggested during these discussions that a Best Current > Practices (BCP) document be written for JSON Web Tokens (JWTs). > > I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have > produced an initial draft of a JWT BCP. Its abstract is: > > JSON Web Tokens, also known as JWTs [RFC7519 > ], are URL-safe JSON-based > security tokens that contain a set of claims that can be signed and/or > encrypted. JWTs are being widely used and deployed as a simple > security token format in numerous protocols and applications, both in > the area of digital identity, and in other application areas. The goal > of this Best Current Practices document is to provide actionable > guidance leading to secure implementation and deployment of JWTs. > > In Section 2, we describe threats and vulnerabilities. In Section 3, > we describe best practices addressing those threats and > vulnerabilities. We believe that the best practices in Sections 3.1 > through 3.8 are ready to apply today. Section 3.9 (Use Mutually > Exclusive Validation Rules for Different Kinds of JWTs) describes > several possible best practices on that topic to serve as a starting > point for a discussion on which of them we want to recommend under > what circumstances. > > We invite input from the OAuth Working Group and other interested > parties on what best practices for JSON Web Tokens and the JOSE > functions underlying them should be. We look forward to hearing your > thoughts and working on this specification together. > > The specification is available at: > > * https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00 > > An HTML-formatted version is also available at: > > * http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html > > -- Mike > > P.S. This notice was also posted at http://self-issued.info/?p=1690 > and as @selfissued > . > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------A3A3A43D55B0EA61E0094038 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Comments on draft-sheffer-oauth-jwt-bcp-00

1. Section 2 lists 7 known and possible threats and vulnerabilities with JWT implementations and deployments.
In the OAuth Threat Model Document (RFC 6819) collusions between users located inside of a system are not mentioned
but nevertheless need to be considered. One threat should be added in this document: Client collusions

Text proposal:
2.8 Client collusions

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 identifies security threats coming
from hostile parties but does not mention threats coming from collaborating parties.

JWTs are issued to a token requestor and are normally intended to be used by that token requestor. They are cases where
the forwarding of a JWT to another party is a desirable property so that it can be used by that other party. This is typically the case
when a JWT is intended to be used for delegation purposes.

However, there are cases where a JWT does not contain a "sub" claim, but other claims that do not allow to identify the token requestor.
This is typically the case when a JWT contains an attribute specifying that the token holder is over 18. In such a case, the forwarding of
such a JWT to another party would not be a desirable property and should be detected by target servers.

Access token binding protection methods currently developed either by the Token Binding WG [Token Binding WG] or by the OAuth WG [OAuth WG]
do not allow to counter the forwarding of a JWT legitimately obtained by a party to another party. Either the legitimate party can provide keys
to the other party, or if it can't (because private keys are protected by a secure element) it can send requests to his secure element to perform
the cryptographic computations that the other party needs.

Whatever kind of cryptographic is being used, when two parties are willing to collaborate, a software-only solution will be unable to
prevent the transfer of an attribute of a party that possesses it to another party that does not possess it. The use of a secure element
will be mandatory.

However, the use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be insufficient.
Additional functional and security properties will be required for the secure elements.

The documents related to OAuth 2.0 do not currently specify how to support secure elements so that the forwarding of a JWT legitimately obtained
by a party to another party can be detected by the target server. Unless some extensions are being defined, the OAuth 2.0 framework will be unable
to support JWTs containing attributes that do not allow to fully identify the token holder, typically a single attribute specifying that the token holder
is over 18.

2. Section 3 lists some best practices. Section 3.8 is written as follows:
3.8.  Use and Validate Audience
   If the same issuer can issue JWTs that are intended for use by more
   than one relying party or application, the JWT MUST contain an "aud"
   (audience) claim that can be used to determine whether the JWT is
   being used by an intended party or was substituted by an attacker at
   an unintended party.
JWTs may be used in a number of contexts, in particular when the resource owner and the target server are not collocated.

If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual or entity
has accessed which target service and may keep a log of that activity. It would thus be in a position to act as Big Brother.

Mandating implementations to have built-in Big Brother properties does not seem to be a "good practice".

However, there is indeed the need to restrict the use of JWTs to specific targets. The key point is that the target service must be able
to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to the target service and
that challenge may then be placed into a specific filed of the JWT. The target service may then verify that the value included
in the JWT is the one that has been recently provided.

A parameter specifying the type of the control value and the value of the control would need to be used.
This parameter would be called a target_id (tid). It would solve the Big Brother case.

This parameter cannot be introduced in a BCP document, but this should be done in another document.

When the resource owner and the target server are not collocated and when privacy is a concern, the use of these parameters
should be deprecated and the use of a "tid" parameter should be recommended.

In any case, stating that "the JWT MUST contain an "aud" (audience) claim" is incorrect.

Denis

JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) functions underlying them are now being widely used in diverse sets of applications.  During IETF 98 in Chicago, we discussed reports of people implementing and using JOSE and JWTs insecurely, the causes of these problems, and ways to address them.  Part of this discussion was an invited JOSE/JWT Security Update presentation that I gave to two working groups, which included links to problem reports and describes mitigations.  Citing the widespread use of JWTs in new IETF applications, Security Area Director Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written for JSON Web Tokens (JWTs).

 

I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have produced an initial draft of a JWT BCP.  Its abstract is:

JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.

 

In Section 2, we describe threats and vulnerabilities.  In Section 3, we describe best practices addressing those threats and vulnerabilities.  We believe that the best practices in Sections 3.1 through 3.8 are ready to apply today.  Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) describes several possible best practices on that topic to serve as a starting point for a discussion on which of them we want to recommend under what circumstances.

 

We invite input from the OAuth Working Group and other interested parties on what best practices for JSON Web Tokens and the JOSE functions underlying them should be.  We look forward to hearing your thoughts and working on this specification together.

 

The specification is available at:

 

An HTML-formatted version is also available at:

 

                                                       -- Mike

 

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



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


--------------A3A3A43D55B0EA61E0094038-- From Brig.Lamoreaux@microsoft.com Thu May 25 09:23:45 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A2F129562 for ; Thu, 25 May 2017 09:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKhDGdpLWbO3 for ; Thu, 25 May 2017 09:23:43 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0134.outbound.protection.outlook.com [104.47.34.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9E3129406 for ; Thu, 25 May 2017 09:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n8p5skOlbFMF7qyr/3UzwbAnP0GlOUVRR4BNlIqmZJI=; b=L+0tv6VglmVYBUDUOJ1Ln+DRjZ8DVSiaN+uZXmAMtU8i90aVn9cXPhXdLXw3DMkJjDro4rnlBbLuPIrLewg2h0CkL5q3vl4BLyjh/e1Q+gWnjBu6HZJKJrl/lQcTHvSS2Rl85vF3gZ4VhCH0fzsPMoYm9qW9efBHwhzFxf1w8N4= Received: from CY4PR03MB2920.namprd03.prod.outlook.com (10.175.116.22) by CY4PR03MB2920.namprd03.prod.outlook.com (10.175.116.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Thu, 25 May 2017 16:23:42 +0000 Received: from CY4PR03MB2920.namprd03.prod.outlook.com ([10.175.116.22]) by CY4PR03MB2920.namprd03.prod.outlook.com ([10.175.116.22]) with mapi id 15.01.1101.019; Thu, 25 May 2017 16:23:42 +0000 From: Brig Lamoreaux To: "oauth@ietf.org" Thread-Topic: RFC 7009 Thread-Index: AdLVcSY9VMwm5v7UR7a29hVsc2krjw== Date: Thu, 25 May 2017 16:23:12 +0000 Deferred-Delivery: Thu, 25 May 2017 16:22:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [72.223.34.197] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR03MB2920; 7:dYhiByQ46ciYoulfBhhZCELAuX+xF/vqdF/fSNKcgmOzFbUyJoDR2XeWNN8uJoWrPphw12hmxIGERdxSsUoLtqK9lAe9vuEhLgbkz25z+bUtiJ7iVOT29eBkyOd6RshpniKBUqGYZlI4OB7OSvmGjHTjutI71jIJanZ60X1gsY9lufKMG8usTn1ztRXBn1SKZYd1ekAjeyTS76DIZUgw0G67JmrRmB5Zva8O0unomNZXevysBmzsd5KaSmyAss/SUUDJA5hSWP1JZECPqXDp97EQnmJCtxxXvyA4zgNQCI7vdmo+UxartyixlP7oc6UyWO3n1ZuzRng0/qmcwNMsRoe7n8H/6k2xrbVKz/dvXW4= x-ms-traffictypediagnostic: CY4PR03MB2920: x-ms-office365-filtering-correlation-id: 0f527ba3-fcea-467c-5af2-08d4a38a68ad x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR03MB2920; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY4PR03MB2920; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2920; x-forefront-prvs: 0318501FAE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39450400003)(39850400002)(39400400002)(39410400002)(2351001)(25786009)(122556002)(74316002)(38730400002)(77096006)(5005710100001)(110136004)(733005)(8990500004)(54356999)(99286003)(55016002)(66066001)(2900100001)(6666003)(7736002)(189998001)(6436002)(5640700003)(3280700002)(72206003)(3660700001)(99936001)(478600001)(2906002)(10090500001)(6506006)(8936002)(86362001)(9326002)(236005)(50986999)(1730700003)(790700001)(7696004)(8676002)(10290500003)(9686003)(5630700001)(81166006)(3846002)(2501003)(54556002)(54896002)(6916009)(6306002)(53936002)(102836003)(86612001)(5660300001)(7116003)(6116002)(33656002)(558084003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2920; H:CY4PR03MB2920.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_CY4PR03MB2920241827103D122E9EC82085FF0CY4PR03MB2920namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2017 16:23:42.1487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2920 Archived-At: X-Mailman-Approved-At: Tue, 06 Jun 2017 08:20:59 -0700 Subject: [OAUTH-WG] RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 16:27:46 -0000 --_004_CY4PR03MB2920241827103D122E9EC82085FF0CY4PR03MB2920namp_ Content-Type: multipart/alternative; boundary="_000_CY4PR03MB2920241827103D122E9EC82085FF0CY4PR03MB2920namp_" --_000_CY4PR03MB2920241827103D122E9EC82085FF0CY4PR03MB2920namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, What is the specified timeout period to invalidate the token? Brig Lamoreaux Data Solution Architect brig.lamoreaux@microsoft.com 480-828-8707 US Desert/Mountain Tempe [MSFT_logo_Gray DE sized SIG1.png] --_000_CY4PR03MB2920241827103D122E9EC82085FF0CY4PR03MB2920namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,


What is the specified timeout period to invalidate the token?

 

Brig Lamoreaux<= /span>

Data Sol= ution Architect

brig.lamoreaux@micr= osoft.com

480-828-= 8707

US Deser= t/Mountain Tempe

 

 

3D"=

 

 

 

--_000_CY4PR03MB2920241827103D122E9EC82085FF0CY4PR03MB2920namp_-- --_004_CY4PR03MB2920241827103D122E9EC82085FF0CY4PR03MB2920namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2721; creation-date="Thu, 25 May 2017 16:23:12 GMT"; modification-date="Thu, 25 May 2017 16:23:12 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAwADAAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA6ARIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCKiiiv mLprc/Q9JyWgV1PhA40m+HtXLetdT4RH/Epva2opdzzc3Ufq0iEdG+tH8NA6N9aB92uFpc58BdMD 938K67wz/wAg0fWuRPSuu8M/8g0fWvQwFvamlFK5sY9OKQAjhmznpQ33TWB4n8RSaEYdkPmB6986 joOvQ4oOPvdTXJ6D4zbVdRNrNAI89DmusACjigAzx81JnnaDSF9odj/CM1xN74/kgnljitgwQ4zT A7gdcelHXjpisnTtXku/D41F48OVJwKwNA8aXWp6wLOWAqhYjOKAO3ooopAFFFJQAtFFFABRRRQA UUUlAC0UUUAFFFFADe2DyaOAOTimTSrBC8rdFGa861HxHqus6o1ppuQFOOKYHo/B6Y96MAtnHK9K 5vwxFqljFcyazNxxgk9K27TUrW+kdLaUOY+uKQFyiiigDxTil49q6b+wNC/6CdH/AAj+g/8AQTry Fl2It8J9Ss+wP8xzAIBHRa6jwiQulX67s5praBoDfe1OtrQ9LsLW1nS1ufMVhyfSnHBYiGricOLz LCYijKMZamCuOfm70cf3q3Bo1hz/AKV3o/sWw/5+q8t0/f3Pn1hmYZzsA2gfjXX+HB/xLlrLOiae cbromt3SLeG1tAkDb1z1rtwMP3u4RouLNCuI+InS1+tdvXD/ABG+5bfWvdNTl2SXSbi1vOQrkYNe sWNwl3ZxTRnKso5rir7TBf8Aga3nA/eRDINXvAGqfaLF7JzzB0z3oA0/FmojTtFl2HEkgwteay2j JYR3MuQJCSp9a6LxletqOuw6fEchGxxS+M7RLHSbC1A+6KYHR+F2RPC0TS8xBTn6VBouoeHp9UeO wiAnzycU/wAP8+DQByNhrlfBe3/hJOI8Es2TQB6TPPHbRNLMwVR3Nc3c+PNMtpmijy+3uKxvHWrX EuoJp1s5AJw2K1NC8FWMNjHJdpvlYZOaQGlo/iux1qYwW7ESDsaLrxRp9pqH2OVv3wOKWx8MWOna kL20TYSORXB+KFB8TyGFP3jNigDtdQ8Z6bYXSwFt3TJHvWrNqdvbWq3M0gRHXcua52w8D2ZsY5Lw l5zh2JrnPEV3Lq+tppsblYYSFUCgDp5/iBpsb4QF1HUitHS/FWl6u3lwzBX9DxVWw8F6Tb2qCeES ORyTXJ+KdCGh3yXVoSqZyAOKAPS5ZFiQu7AIo+Y1zt5450y1laJPnK9CKpahqdxe+BmuoyQcYfHW sfwdDolwHW/2tKfu7jQB2Wi+J7HWpGityQ69RWjd31vp8ZkuZQo96oadoGn6ddvd2aqA47GuG8S3 0+s699hViEVscGgDpZfiBpySEIC6561p6X4p0zVn8uGYCT0PFVbDwZpMNogmhEjkcmuS8UaH/YN+ l1aMVTOQBxTA6/xH4hsdPhks5n2zSLhR61xXhjUbbSdRNxdfKGJINdKLKz1/w4mqXcW+5VOG9MVz nhXT7fVtUkhu13qhIC0Ab2v+LNN1HR5ra1ctK/AxWV4P1u00MTLesVaT1rZ8Q+F9MsNHmubWPZIn INZXg3R7PWhM17HvaPpSA6L/AITvSP8AnoaKl/4QnRv+eFFAHnYHuaTHuacKK+wsrI/N3J33GY+t dZ4Q/wCQdeVytdX4Q/5B15XmZurYKTR7GTtvGRTJVXr9aXbQvf60V+KylLufqKSD0rodF/48xXPC uh0X/j0Fezk7f1g5MYlymiPyrh/iN9y23Nxmu5rj/HWnX2oi3Wzg3kdTX2h5Jo+HYFuPDEcT8xsp GK4q3nfw14jl3Z2DOR9a7/w5azWuhwQXC4kQfMK5/wAZ+H7m+kju7KLMjcOKAM7wlZtq2vzag+TG jZGaufEUDNqeoHSt/wALaUdM0dIpU2yty1ZfjjTL7UlgFlHu8vrQBa0A58H8HHyGuX8GEf8ACTtj +8a6/RrO4h8Li3lTEu0jFc74W0TUrHxB59xFiJicGgDM8Uq9r4teST/VlwQa9KsbhLm0hliIZWUZ rG8U+G11mIPFxMvf1rk7ePxRoga3hDMoPy0Aem7lzjIB9M15drhDeMjuJChx2963/DNvr0+rNd6m zCMDhaoazouq3Pih7yO2zbK45oA71Rm3AH/PP+leVuTZeLssMASdT9a9WiGI0P8AsiuW8UeE21Nz c2fyzHmgDqYnWSJGUggrXEfEO6i2W8KsC/NZ0EnivTz9kUMwAwDUmneFdU1i9FzqrEBGyAaAOh8K WCP4YWG6AKzA5DVj6t4DeEebYPwMsQDjFb/iOwvDoyw6WpEkeMY4rl/7Q8XeUbaRWbcNvSgCTwdr N2NSOmzkmNwQAT0rKc/2f4yxJ/q0f5s/Wum8I+GLmzu21DUOJf4B6VJ4p8KNqU/2yx4m/i96AOrj ZZY0dCCpFcR8RLmI/ZoFYF+eKzYZvFdgn2VVZscA1Np/hbVNYvlutVYgIcgGgDZ0SGSHwQwbO7aT isHwIQ+tucFSCa727tSNKe3tkGQmAK5Dwfo2qWWryT3kOyMk4NAHReMOPDlxWF8OipFwR3rqtXs/ 7R02W2HVhxXndvp/iDQbuZbRGKseMCgD1LP0orzrPjI84PNFAGCKSlFJX2PRH5s9wrq/CH/IOvK5 Sur8If8AIOvK8vN/9ykexk3++RJ17/Wihe/1or8UkfqaEFdDov8Ax6CueFdDov8Ax6CvZyf/AHg4 8b8JpUUUtfankhSUtFABSUtFACUYpaKACkKg9QD+FLRQAgGOlFLRQAUUUUAJtXOcDP0o6UtFABSb V/uj8qWigAooooATapOdoz9KKWigAooooAKQqp6gH8KWigBKKWigD//Z --_004_CY4PR03MB2920241827103D122E9EC82085FF0CY4PR03MB2920namp_-- From nobody Tue Jun 6 09:12:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14A712940C for ; Tue, 6 Jun 2017 09:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvI3zBIpUv4B for ; Tue, 6 Jun 2017 09:12:12 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 2A382126C83 for ; Tue, 6 Jun 2017 09:12:12 -0700 (PDT) X-AuditID: 1209190d-ec7ff70000006ed0-ea-5936d45ac7a0 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 6D.72.28368.A54D6395; Tue, 6 Jun 2017 12:12:10 -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 v56GC9Jk013667; Tue, 6 Jun 2017 12:12:10 -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 v56GC7Ui022212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jun 2017 12:12:08 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_668E2DCD-BEA2-4400-9CB5-521935C6C6D9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 6 Jun 2017 12:12:07 -0400 In-Reply-To: Cc: "" To: Brig Lamoreaux References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixCmqrBt1xSzS4HebtcWZZ7+ZLU6+fcXm wOSxZMlPJo/WHX/ZA5iiuGxSUnMyy1KL9O0SuDIa9+sU7PeuuDOlnbWB8aVTFyMHh4SAicTu GcZdjFwcQgKLmSTmHD/PAuFsYJSYe/I1E4TzgEliyfHzrF2MnBxsAqoS09e0MIHYvAJWEhNm zWQCmcQskCSxcgcriMkroC/R+5wRpEJYQEHi8JKjzCA2i4CKxKKdf9hAbE6BWImbfd3sEJ3q Eu0nXUDCIgKGEq0z2sAWCQnESPz70A1mSwjIStyafYl5AiP/LIRdsxB2zQIqYhbQlli28DUz hK0psb97OQumuIZE57eJrAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGunlZpbopaaUbmIE B7Mk7w7Gf3e9DjEKcDAq8fAK7DKLFGJNLCuuzD3EKMnBpCTKG3kJKMSXlJ9SmZFYnBFfVJqT WnyIUYKDWUmE99YaoBxvSmJlVWpRPkxKmoNFSZxXXKMxQkggPbEkNTs1tSC1CCYrw8GhJMH7 GGSoYFFqempFWmZOCUKaiYMTZDgP0PA/p0CGFxck5hZnpkPkTzEqSonzsoM0C4AkMkrz4HpB ySbh7WHTV4ziQK8I894HqeIBJiq47ldAg5mABvNdMgEZXJKIkJJqYJzAtirju926H8/u1zRI TedSMveWrltgnXlrdtTiAwolk2xmfuribfn88/0O2aKojzczp34ovbyY4Wzmh+QSV+ajuh1f bjunr2wLy39sNCNQ8ckvtpWWAgtYrJb53M15tmVbyy0+x0TzXZyPfp7IdHqhU9FWu69RX/G3 wr2Pqhy9BX0nH7ute6HEUpyRaKjFXFScCADx0KwJEQMAAA== Archived-At: Subject: Re: [OAUTH-WG] RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 16:12:15 -0000 --Apple-Mail=_668E2DCD-BEA2-4400-9CB5-521935C6C6D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OAuth doesn=E2=80=99t specify and specific timeout period, it=E2=80=99s = up to the AS that issues the token to determine how long the token is = good for. RFC7009 isn=E2=80=99t about timeout periods, it=E2=80=99s = about the client proactively telling the AS that it doesn=E2=80=99t need = a token anymore and the AS should throw it out, likely prior to any = timeouts. =E2=80=94 Justin > On May 25, 2017, at 12:23 PM, Brig Lamoreaux = wrote: >=20 > Hi, >=20 > What is the specified timeout period to invalidate the token? > =20 > Brig Lamoreaux > Data Solution Architect > brig.lamoreaux@microsoft.com > 480-828-8707 > US Desert/Mountain Tempe > =20 > =20 > > =20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_668E2DCD-BEA2-4400-9CB5-521935C6C6D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OAuth doesn=E2=80=99t specify and specific timeout period, = it=E2=80=99s up to the AS that issues the token to determine how long = the token is good for. RFC7009 isn=E2=80=99t about timeout periods, = it=E2=80=99s about the client proactively telling the AS that it = doesn=E2=80=99t need a token anymore and the AS should throw it out, = likely prior to any timeouts.

 =E2=80=94 Justin

On = May 25, 2017, at 12:23 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> wrote:

Hi,

What is the specified timeout period to = invalidate the token?
 
Brig Lamoreaux
Data Solution Architect
480-828-8707
US Desert/Mountain = Tempe
 

 

<image001.jpg>

 

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

= --Apple-Mail=_668E2DCD-BEA2-4400-9CB5-521935C6C6D9-- From nobody Tue Jun 6 14:45:52 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269EC128B93 for ; Tue, 6 Jun 2017 14:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnPsUsP31cth for ; Tue, 6 Jun 2017 14:45:48 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.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 000BE12741D for ; Tue, 6 Jun 2017 14:45:47 -0700 (PDT) X-AuditID: 12074425-493ff70000007be9-1d-5937228a88c6 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 AD.B4.31721.A8227395; Tue, 6 Jun 2017 17:45:46 -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 v56LjksR006081; Tue, 6 Jun 2017 17:45:46 -0400 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 v56LjhQp005479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Jun 2017 17:45:45 -0400 To: Brig Lamoreaux Cc: "" References: From: Justin Richer Message-ID: Date: Tue, 6 Jun 2017 17:45:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D1ED24264F5B953546B3A265" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixG6notulZB5psH6blcWZZ7+ZLU6+fcXm wOSxZMlPJo/WHX/ZA5iiuGxSUnMyy1KL9O0SuDLOnJArOFRV8eroEcYGxnWhXYycHBICJhJr vnezdjFycQgJLGaS2P0WxtnAKHFucR8bSJWQwC0mieOPJEBsYQEFicNLjjKD2CIChhKtM9qA Gjg4mAXUJdpPukD0PmCUeDVzNjtIDZuAqsT0NS1MIDavgJVEz8kPjCA2i4CKxK6+FrD5ogIx Eo82nIWqEZQ4OfMJC4jNKRArcfX0BFYQm1kgTGLT/25mCFtc4taT+UwTGAVmIWmZhaRsFpIy CNtMYt7mh1BxeYnmrbOBbJCz1SSWtSohCy9gZF/FKJuSW6Wbm5iZU5yarFucnJiXl1qka6GX m1mil5pSuokRHAUuqjsY5/z1OsQowMGoxMMrsMssUog1say4MvcQoyQHk5Iob+QloBBfUn5K ZUZicUZ8UWlOavEhRgkOZiUR3p7PQDnelMTKqtSifJiUNAeLkjivuEZjhJBAemJJanZqakFq EUxWhoNDSYI3RNE8UkiwKDU9tSItM6cEIc3EwQkynAdoeLUMUA1vcUFibnFmOkT+FKOilDiv AkizAEgiozQPrheUpBLeHjZ9xSgO9IowbyxIFQ8wwcF1vwIazAQ0mO+SCcjgkkSElFQDI0Om z6yAxW3z7/SnZ2dxtl1cNGOS2YHIE3bRCoZZEZdEp8Qn9uj97hRVYFV75K8T/GPzh5Ye9XbB pU+ef9dpZYj1LOa54m+//0ldiZTLjB+XPDZ2zLJ5apMhqDR/8owzXkLHXvW/dhTia+6L+Pb5 wUa3KUUz8m76a7BWHVj58EXH6eePLnfvUmIpzkg01GIuKk4EAOalLkEtAwAA Archived-At: Subject: Re: [OAUTH-WG] RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 21:45:50 -0000 This is a multi-part message in MIME format. --------------D1ED24264F5B953546B3A265 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 7009 doesn't, really. If the client thinks its token is compromised, it can revoke it using 7009. If the server decides the token is compromised, it invalidates it on its own, not involving 7009. The client finds out the token isn't good anymore the next time it tries to use the token -- OAuth clients always need to be prepared for their token not working at some point. Good news is that the remedy for having a token that doesn't work is to just do OAuth again. -- Justin On 6/6/2017 5:43 PM, Brig Lamoreaux wrote: > > Thanks for the reply. How do the RFC address a token that has been > compromised? > > *From:*Justin Richer [mailto:jricher@mit.edu] > *Sent:* Tuesday, June 6, 2017 9:12 AM > *To:* Brig Lamoreaux > *Cc:* > *Subject:* Re: [OAUTH-WG] RFC 7009 > > OAuth doesn’t specify and specific timeout period, it’s up to the AS > that issues the token to determine how long the token is good for. > RFC7009 isn’t about timeout periods, it’s about the client proactively > telling the AS that it doesn’t need a token anymore and the AS should > throw it out, likely prior to any timeouts. > > — Justin > > On May 25, 2017, at 12:23 PM, Brig Lamoreaux > > wrote: > > Hi, > > > What is the specified timeout period to invalidate the token? > > Brig Lamoreaux > > Data Solution Architect > > brig.lamoreaux@microsoft.com > > 480-828-8707 > > US Desert/Mountain Tempe > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------D1ED24264F5B953546B3A265 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

7009 doesn't, really. If the client thinks its token is compromised, it can revoke it using 7009. If the server decides the token is compromised, it invalidates it on its own, not involving 7009. The client finds out the token isn't good anymore the next time it tries to use the token -- OAuth clients always need to be prepared for their token not working at some point. Good news is that the remedy for having a token that doesn't work is to just do OAuth again.

 -- Justin


On 6/6/2017 5:43 PM, Brig Lamoreaux wrote:

Thanks for the reply. How do the RFC address a token that has been compromised?

 

From: Justin Richer [mailto:jricher@mit.edu]
Sent: Tuesday, June 6, 2017 9:12 AM
To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] RFC 7009

 

OAuth doesn’t specify and specific timeout period, it’s up to the AS that issues the token to determine how long the token is good for. RFC7009 isn’t about timeout periods, it’s about the client proactively telling the AS that it doesn’t need a token anymore and the AS should throw it out, likely prior to any timeouts.

 

 — Justin

 

On May 25, 2017, at 12:23 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> wrote:

 

Hi,


What is the specified timeout period to invalidate the token?

 

Brig Lamoreaux

Data Solution Architect

480-828-8707

US Desert/Mountain Tempe

 

 

<image001.jpg>

 

 

 

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

 


--------------D1ED24264F5B953546B3A265-- From nobody Tue Jun 6 15:18:39 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3209A129410 for ; Tue, 6 Jun 2017 15:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy1b1lNUidRM for ; Tue, 6 Jun 2017 15:18:30 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E33128B93 for ; Tue, 6 Jun 2017 15:18:30 -0700 (PDT) X-AuditID: 1209190f-0ddff70000000a50-29-59372a347bab 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 38.FB.02640.43A27395; Tue, 6 Jun 2017 18:18:29 -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 v56MIRig012569; Tue, 6 Jun 2017 18:18:27 -0400 Received: from [192.168.128.48] (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 v56MIPpS015302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jun 2017 18:18:26 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B947A3B8-7DA5-4908-9788-94BBD8A7BA24" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 6 Jun 2017 18:18:24 -0400 In-Reply-To: Cc: "" To: Brig Lamoreaux References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT0TXVMo80WHZP0OLMs9/MFiffvmJz YPJYsuQnk0frjr/sAUxRXDYpqTmZZalF+nYJXBmfWxezFTSvZKyYfXgDSwPjtCmMXYwcHBIC JhI7Ztt1MXJxCAksZpKYtvwUG4SzgVHi0rJtzF2MnEDOLSaJuY9VQGw2AVWJ6WtamEBsXgEr iVc3lzKC2MwCSRLfPk1mBRnKK6Av0fscLCwsoCBxeMlRsDEsAioSR/7/ZAOxOQViJabPe8YE Us4soC7RftIFJCwiYCjROqONFWLrEyaJtmXuILaEgKzErdmXmCcw8s9CsmwWwjKIsLbEsoWv mSFsTYn93ctZMMU1JDq/TWRdwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdELzezRC81pXQT IyioOSX5dzDOafA+xCjAwajEw5uxxyxSiDWxrLgy9xCjJAeTkihv5CWgEF9SfkplRmJxRnxR aU5q8SFGCQ5mJRHeOg3zSCHelMTKqtSifJiUNAeLkjivuEZjhJBAemJJanZqakFqEUxWhoND SYI3UhOoUbAoNT21Ii0zpwQhzcTBCTKcB2j4OTWQ4cUFibnFmekQ+VOMilLivAIgWwVAEhml eXC9oKST8Paw6StGcaBXhHlXgVTxABMWXPcroMFMQIP5LpmADC5JREhJNTAaaa8wmr6zVO3k ZPcDExRmTEr6+KLez3vuszCOKzYWX2NXvA5Xvjuvkf3Rnp5fBu8qpjyaWpYnOy12ocOV7rsC i2+llWxPmlHomLFb4Vrdyjsd19bndGTb7D26MflMxJf+zgB/1Zrtf6fN4Zn74KjAw8xNSko3 Ui+ztkycsbBgh0kio+k7Wb/DSizFGYmGWsxFxYkAP++0sxUDAAA= Archived-At: Subject: Re: [OAUTH-WG] RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 22:18:33 -0000 --Apple-Mail=_B947A3B8-7DA5-4908-9788-94BBD8A7BA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That really depends on the nature of your tokens and how you manage = their internal validity. It=E2=80=99s really as soon as possible, = isn=E2=80=99t it? If you can invalidate it immediately, do that. In our = implementation, we delete it from the data store as soon as the = revocation request comes in, which invalidates it. Downstream RS=E2=80=99s= might have cached introspection (RFC7662) results so they=E2=80=99ll = find out once their caches expire. If you=E2=80=99ve got some other = synchronization method that takes some time to propagate, then that=E2=80=99= s going to be the answer. All of this is dependent on your = implementation and not on the revocation protocol, but in all cases I = see no reason to *wait* any amount of time to revoke a token that=E2=80=99= s been requested for revocation by a client, for any reason. The client = is effectively saying =E2=80=9Cif you see this token again it isn=E2=80=99= t from me=E2=80=9D, which should be a good enough indication to throw it = out as soon as possible. This all falls apart if you=E2=80=99re using self-contained tokens =E2=80=94= there=E2=80=99s not a good way to invalidate a self-contained token = without using some kind of lookup service. RFC7662 defines such a = service for OAuth, but then your tokens aren=E2=80=99t really fully = self-contained anymore and you=E2=80=99re simply stuck waiting for the = compromised token to expire. =E2=80=94 Justin > On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux = wrote: >=20 > This is where we have the question around timeouts. If the client = thinks its token is compromised, how long should 7009 take to = invalidate. > =20 > =20 > =C2=A0 <> > From: Justin Richer [mailto:jricher@mit.edu]=20 > Sent: Tuesday, June 6, 2017 2:46 PM > To: Brig Lamoreaux > Cc: > Subject: Re: [OAUTH-WG] RFC 7009 > =20 > 7009 doesn't, really. If the client thinks its token is compromised, = it can revoke it using 7009. If the server decides the token is = compromised, it invalidates it on its own, not involving 7009. The = client finds out the token isn't good anymore the next time it tries to = use the token -- OAuth clients always need to be prepared for their = token not working at some point. Good news is that the remedy for having = a token that doesn't work is to just do OAuth again. >=20 > -- Justin >=20 > =20 > On 6/6/2017 5:43 PM, Brig Lamoreaux wrote: > Thanks for the reply. How do the RFC address a token that has been = compromised? > =20 > From: Justin Richer [mailto:jricher@mit.edu ]=20= > Sent: Tuesday, June 6, 2017 9:12 AM > To: Brig Lamoreaux = > Cc: = > Subject: Re: [OAUTH-WG] RFC 7009 > =20 > OAuth doesn=E2=80=99t specify and specific timeout period, it=E2=80=99s = up to the AS that issues the token to determine how long the token is = good for. RFC7009 isn=E2=80=99t about timeout periods, it=E2=80=99s = about the client proactively telling the AS that it doesn=E2=80=99t need = a token anymore and the AS should throw it out, likely prior to any = timeouts. > =20 > =E2=80=94 Justin > =20 > On May 25, 2017, at 12:23 PM, Brig Lamoreaux = > = wrote: > =20 > Hi, >=20 > What is the specified timeout period to invalidate the token? > =20 > Brig Lamoreaux > Data Solution Architect > brig.lamoreaux@microsoft.com > 480-828-8707 > US Desert/Mountain Tempe > =20 > =20 > > =20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > =20 --Apple-Mail=_B947A3B8-7DA5-4908-9788-94BBD8A7BA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That really depends on the nature of your tokens and how you = manage their internal validity. It=E2=80=99s really as soon as possible, = isn=E2=80=99t it? If you can invalidate it immediately, do that. In our = implementation, we delete it from the data store as soon as the = revocation request comes in, which invalidates it. Downstream RS=E2=80=99s= might have cached introspection (RFC7662) results so they=E2=80=99ll = find out once their caches expire. If you=E2=80=99ve got some other = synchronization method that takes some time to propagate, then that=E2=80=99= s going to be the answer. All of this is dependent on your = implementation and not on the revocation protocol, but in all cases I = see no reason to *wait* any amount of time to revoke a token that=E2=80=99= s been requested for revocation by a client, for any reason. The client = is effectively saying =E2=80=9Cif you see this token again it isn=E2=80=99= t from me=E2=80=9D, which should be a good enough indication to throw it = out as soon as possible.

This all falls apart if you=E2=80=99re using self-contained = tokens =E2=80=94 there=E2=80=99s not a good way to invalidate a = self-contained token without using some kind of lookup service. RFC7662 = defines such a service for OAuth, but then your tokens aren=E2=80=99t = really fully self-contained anymore and you=E2=80=99re simply stuck = waiting for the compromised token to expire.

 =E2=80=94 Justin

On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> wrote:

This is where we have the question around = timeouts. If the client thinks its token is compromised, how long should = 7009 take to invalidate.
 
 
From: Justin Richer [mailto:jricher@mit.edu] 
Sent: Tuesday, June 6, 2017 2:46 = PM
To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] RFC 7009
 

7009 doesn't, = really. If the client thinks its token is compromised, it can revoke it = using 7009. If the server decides the token is compromised, it = invalidates it on its own, not involving 7009. The client finds out the = token isn't good anymore the next time it tries to use the token -- = OAuth clients always need to be prepared for their token not working at = some point. Good news is that the remedy for having a token that doesn't = work is to just do OAuth again.

 -- Justin

 
On 6/6/2017 5:43 PM, Brig Lamoreaux = wrote:
Thanks for the reply. How do the RFC address a = token that has been compromised?
 
From: Justin Richer [mailto:jricher@mit.edu] 
Sent: Tuesday, June 6, 2017 9:12 = AM
To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] RFC = 7009
 
OAuth doesn=E2=80=99t specify and specific timeout = period, it=E2=80=99s up to the AS that issues the token to determine how = long the token is good for. RFC7009 isn=E2=80=99t about timeout periods, = it=E2=80=99s about the client proactively telling the AS that it = doesn=E2=80=99t need a token anymore and the AS should throw it out, = likely prior to any timeouts.
 
 =E2=80=94 Justin
 
On May 25, 2017, at 12:23 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> wrote:
 
Hi,

What is the specified timeout period to = invalidate the token?
 
Brig Lamoreaux
Data Solution = Architect
brig.lamoreaux@microsoft.com
480-828-8707
US Desert/Mountain = Tempe
 
 
<image001.jpg>
 
 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 

= --Apple-Mail=_B947A3B8-7DA5-4908-9788-94BBD8A7BA24-- From nobody Tue Jun 6 15:32:04 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11C7127B5A for ; Tue, 6 Jun 2017 15:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUaLbw2-1BFL for ; Tue, 6 Jun 2017 15:32:00 -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 32FD2126B71 for ; Tue, 6 Jun 2017 15:32:00 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v56MVxt9019722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Jun 2017 22:31:59 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v56MVwL6012789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Jun 2017 22:31:59 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v56MVvKL010584; Tue, 6 Jun 2017 22:31:57 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Jun 2017 15:31:57 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-9D16EA38-1E2B-464A-8487-D83D965C57B2 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 6 Jun 2017 15:31:54 -0700 Cc: Brig Lamoreaux , "" Content-Transfer-Encoding: 7bit Message-Id: References: To: Justin Richer X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [OAUTH-WG] RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 22:32:03 -0000 --Apple-Mail-9D16EA38-1E2B-464A-8487-D83D965C57B2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is why i expect a secevent token revocation event to be defined to comp= lement 7009 once secevents moves further along.=20 We want to be able to know in near real time when a token is revoked to avoi= d constant checks to see if a token is still good.=20 Phil > On Jun 6, 2017, at 3:18 PM, Justin Richer wrote: >=20 > That really depends on the nature of your tokens and how you manage their i= nternal validity. It=E2=80=99s really as soon as possible, isn=E2=80=99t it?= If you can invalidate it immediately, do that. In our implementation, we de= lete it from the data store as soon as the revocation request comes in, whic= h invalidates it. Downstream RS=E2=80=99s might have cached introspection (R= FC7662) results so they=E2=80=99ll find out once their caches expire. If you= =E2=80=99ve got some other synchronization method that takes some time to pr= opagate, then that=E2=80=99s going to be the answer. All of this is dependen= t on your implementation and not on the revocation protocol, but in all case= s I see no reason to *wait* any amount of time to revoke a token that=E2=80=99= s been requested for revocation by a client, for any reason. The client is e= ffectively saying =E2=80=9Cif you see this token again it isn=E2=80=99t from= me=E2=80=9D, which should be a good enough indication to throw it out as so= on as possible. >=20 > This all falls apart if you=E2=80=99re using self-contained tokens =E2=80=94= there=E2=80=99s not a good way to invalidate a self-contained token without= using some kind of lookup service. RFC7662 defines such a service for OAuth= , but then your tokens aren=E2=80=99t really fully self-contained anymore an= d you=E2=80=99re simply stuck waiting for the compromised token to expire. >=20 > =E2=80=94 Justin >=20 >> On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux = wrote: >>=20 >> This is where we have the question around timeouts. If the client thinks i= ts token is compromised, how long should 7009 take to invalidate. >> =20 >> =20 >> =20 >> From: Justin Richer [mailto:jricher@mit.edu]=20 >> Sent: Tuesday, June 6, 2017 2:46 PM >> To: Brig Lamoreaux >> Cc: >> Subject: Re: [OAUTH-WG] RFC 7009 >> =20 >> 7009 doesn't, really. If the client thinks its token is compromised, it c= an revoke it using 7009. If the server decides the token is compromised, it i= nvalidates it on its own, not involving 7009. The client finds out the token= isn't good anymore the next time it tries to use the token -- OAuth clients= always need to be prepared for their token not working at some point. Good n= ews is that the remedy for having a token that doesn't work is to just do OA= uth again. >>=20 >> -- Justin >>=20 >> =20 >> On 6/6/2017 5:43 PM, Brig Lamoreaux wrote: >> Thanks for the reply. How do the RFC address a token that has been compro= mised? >> =20 >> From: Justin Richer [mailto:jricher@mit.edu]=20 >> Sent: Tuesday, June 6, 2017 9:12 AM >> To: Brig Lamoreaux >> Cc: >> Subject: Re: [OAUTH-WG] RFC 7009 >> =20 >> OAuth doesn=E2=80=99t specify and specific timeout period, it=E2=80=99s u= p to the AS that issues the token to determine how long the token is good fo= r. RFC7009 isn=E2=80=99t about timeout periods, it=E2=80=99s about the clien= t proactively telling the AS that it doesn=E2=80=99t need a token anymore an= d the AS should throw it out, likely prior to any timeouts. >> =20 >> =E2=80=94 Justin >> =20 >> On May 25, 2017, at 12:23 PM, Brig Lamoreaux wrote: >> =20 >> Hi, >>=20 >> What is the specified timeout period to invalidate the token? >> =20 >> Brig Lamoreaux >> Data Solution Architect >> brig.lamoreaux@microsoft.com >> 480-828-8707 >> US Desert/Mountain Tempe >> =20 >> =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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&= r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D7yMIczBrZnmQ14Nkf4MBGaIH= nxRyiLGXB1Xhuxp1Ur0&s=3DTaKHdPgtEPkCV_YuOHlkoXRZJjf0k8Y4-yowD3YbhPw&e=3D=20 --Apple-Mail-9D16EA38-1E2B-464A-8487-D83D965C57B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This is why i expect a secevent token r= evocation event to be defined to complement 7009 once secevents moves furthe= r along. 

We want to be able to know in near real time when a token is= revoked to avoid constant checks to see if a token is still good. 
=
Phil

On Jun 6, 2017, at 3:18 PM, Justin Richer <jricher@mit.edu> wrote:

That really depends on the nature of your tokens a= nd how you manage their internal validity. It=E2=80=99s really as soon as po= ssible, isn=E2=80=99t it? If you can invalidate it immediately, do that. In o= ur implementation, we delete it from the data store as soon as the revocatio= n request comes in, which invalidates it. Downstream RS=E2=80=99s might have= cached introspection (RFC7662) results so they=E2=80=99ll find out once the= ir caches expire. If you=E2=80=99ve got some other synchronization method th= at takes some time to propagate, then that=E2=80=99s going to be the answer.= All of this is dependent on your implementation and not on the revocation p= rotocol, but in all cases I see no reason to *wait* any amount of time to re= voke a token that=E2=80=99s been requested for revocation by a client, for a= ny reason. The client is effectively saying =E2=80=9Cif you see this token a= gain it isn=E2=80=99t from me=E2=80=9D, which should be a good enough indica= tion to throw it out as soon as possible.

This all falls apart if you=E2=80=99re using self-containe= d tokens =E2=80=94 there=E2=80=99s not a good way to invalidate a self-conta= ined token without using some kind of lookup service. RFC7662 defines such a= service for OAuth, but then your tokens aren=E2=80=99t really fully self-co= ntained anymore and you=E2=80=99re simply stuck waiting for the compromised t= oken to expire.

&n= bsp;=E2=80=94 Justin

On Jun 6, 2017, at 6:11 PM, Brig Lamo= reaux <Brig.La= moreaux@microsoft.com> wrote:

This is where we have= the question around timeouts. If the client thinks its token is compromised= , how long should 7009 take to invalidate.
 =
 
 
From:<= span class=3D"Apple-converted-space"> Justin Richer [mailto:jricher@mit.edu] 
Sent:<= span class=3D"Apple-converted-space"> Tuesday, June 6, 2017 2:46= PM
To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH= -WG] RFC 7009
 

7009 doesn't= , really. If the client thinks its token is compromised, it can revoke it us= ing 7009. If the server decides the token is compromised, it invalidates it o= n its own, not involving 7009. The client finds out the token isn't good any= more the next time it tries to use the token -- OAuth clients always need to= be prepared for their token not working at some point. Good news is that th= e remedy for having a token that doesn't work is to just do OAuth again.

 -- Justin

 
On 6/6/2017 5:43 PM, Brig Lamoreaux w= rote:
Thanks fo= r the reply. How do the RFC address a token that has been compromised?
 =
From: Just= in Richer [mailto:jricher@mit.edu] 
Sent: Tuesday, June 6, 2017 9:12 A= M
To:&= nbsp;Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
Cc:&= nbsp;<oauth@ietf.org> <oauth@ietf.org&g= t;
Subject: Re: [OAUTH-WG] RFC 7009
 =
OAuth doesn=E2=80=99t specify and speci= fic timeout period, it=E2=80=99s up to the AS that issues the token to deter= mine how long the token is good for. RFC7009 isn=E2=80=99t about timeout per= iods, it=E2=80=99s about the client proactively telling the AS that it doesn= =E2=80=99t need a token anymore and the AS should throw it out, likely prior= to any timeouts.
 
 =E2=80=94 Justin
 
On M= ay 25, 2017, at 12:23 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> wrote:
 
Hi,
=
What is the specified timeout period to invalidate the toke= n?
 
=
Brig Lamoreaux
Data Solution Archi= tect
b= rig.lamoreaux@microsoft.co= m
480-828-8707
US Desert/Mountain Tempe
 
 
<image001.jpg>=
 
 
 
____________________= ___________________________
OAuth mailing list
<= /span>OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 
= --Apple-Mail-9D16EA38-1E2B-464A-8487-D83D965C57B2-- From nobody Wed Jun 7 06:15:12 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA0C128BB6 for ; Tue, 6 Jun 2017 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVKijBZ4p8tB for ; Tue, 6 Jun 2017 14:43:29 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0139.outbound.protection.outlook.com [104.47.41.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1A91286AB for ; Tue, 6 Jun 2017 14:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YBEKIJhz4TGSsFfjDXBgT2HN8MH6jEqKlhzFOoxIW9w=; b=ZcoOgIFWsEcKb/rD/F0aTn33aeVTET7dW52gAlAGzA9pBKomRIhRhTv83BSN9byj9cy3KglrZqqs+bxj7jJLWxqWR3IY04T5CtRZq2hT9w087Hpdk/y25vTXQ94Eq1ROlgvhMbmOpeBmbpiMT3o5HxnCFQY4XfurHYFl760H9VQ= Received: from DM5PR03MB2922.namprd03.prod.outlook.com (10.175.106.20) by DM5PR03MB2923.namprd03.prod.outlook.com (10.175.106.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Tue, 6 Jun 2017 21:43:28 +0000 Received: from DM5PR03MB2922.namprd03.prod.outlook.com ([10.175.106.20]) by DM5PR03MB2922.namprd03.prod.outlook.com ([10.175.106.20]) with mapi id 15.01.1157.012; Tue, 6 Jun 2017 21:43:28 +0000 From: Brig Lamoreaux To: Justin Richer CC: "" Thread-Topic: [OAUTH-WG] RFC 7009 Thread-Index: AdLVcSY9VMwm5v7UR7a29hVsc2krjwJbn5+AAAt1W1A= Date: Tue, 6 Jun 2017 21:43:20 +0000 Deferred-Delivery: Tue, 6 Jun 2017 21:43:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [72.223.34.197] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR03MB2923; 7:EwcfTtgpbGcKBAEmexlPPthxYOthpaOOW9MD4C55MJlDd45mGhLfPZ+Me7inqCYxt7Tl7Sd0KT8TyjRlUKng6j6H6p8mxB4Y1P6wRKmErN8QS9l/cmjtjjBTrkfTcJViphV2FEwvIdzC0ztMi6iUlUbB3dzQlUzi1s2pMGsiA2oXiuJ5YWIrwkW3BFoO1EcT26Q8/6+t9lmHDep/MjPlHUSY2Rx6Xf+s1hdCUbIvvYbbQayNV/fNuCfzEu2CXC9PNhglyjKv310AJBpbkQvNWxc8RTfNTyiGL/x1HMqB/mYswOfADi6oYdQp56IBq0s63uUtSq2vX5HGgzIqiRwQ6i1UejG3EjAOBYiqWqzsm/k= x-ms-traffictypediagnostic: DM5PR03MB2923: x-ms-office365-filtering-correlation-id: beab79aa-873c-453f-cb84-08d4ad251142 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM5PR03MB2923; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR03MB2923; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR03MB2923; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(377454003)(24454002)(81166006)(2950100002)(33656002)(2906002)(6436002)(5005710100001)(8676002)(86362001)(3846002)(102836003)(72206003)(10090500001)(478600001)(790700001)(6116002)(53546009)(14454004)(966005)(5660300001)(7736002)(7906003)(3280700002)(55016002)(74316002)(3660700001)(8936002)(229853002)(25786009)(4326008)(6666003)(7696004)(6916009)(54896002)(6306002)(99286003)(66066001)(6506006)(2900100001)(9686003)(236005)(54356999)(76176999)(606005)(50986999)(122556002)(2171002)(10290500003)(77096006)(6246003)(38730400002)(110136004)(189998001)(19609705001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR03MB2923; H:DM5PR03MB2922.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR03MB292263A0429C2BEE01E95BB085CB0DM5PR03MB2922namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 21:43:28.0130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2923 Archived-At: X-Mailman-Approved-At: Wed, 07 Jun 2017 06:15:09 -0700 Subject: Re: [OAUTH-WG] RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 21:43:31 -0000 --_000_DM5PR03MB292263A0429C2BEE01E95BB085CB0DM5PR03MB2922namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVwbHkuIEhvdyBkbyB0aGUgUkZDIGFkZHJlc3MgYSB0b2tlbiB0aGF0 IGhhcyBiZWVuIGNvbXByb21pc2VkPw0KDQpGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJp Y2hlckBtaXQuZWR1XQ0KU2VudDogVHVlc2RheSwgSnVuZSA2LCAyMDE3IDk6MTIgQU0NClRvOiBC cmlnIExhbW9yZWF1eCA8QnJpZy5MYW1vcmVhdXhAbWljcm9zb2Z0LmNvbT4NCkNjOiA8b2F1dGhA aWV0Zi5vcmc+IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJGQyA3 MDA5DQoNCk9BdXRoIGRvZXNu4oCZdCBzcGVjaWZ5IGFuZCBzcGVjaWZpYyB0aW1lb3V0IHBlcmlv ZCwgaXTigJlzIHVwIHRvIHRoZSBBUyB0aGF0IGlzc3VlcyB0aGUgdG9rZW4gdG8gZGV0ZXJtaW5l IGhvdyBsb25nIHRoZSB0b2tlbiBpcyBnb29kIGZvci4gUkZDNzAwOSBpc27igJl0IGFib3V0IHRp bWVvdXQgcGVyaW9kcywgaXTigJlzIGFib3V0IHRoZSBjbGllbnQgcHJvYWN0aXZlbHkgdGVsbGlu ZyB0aGUgQVMgdGhhdCBpdCBkb2VzbuKAmXQgbmVlZCBhIHRva2VuIGFueW1vcmUgYW5kIHRoZSBB UyBzaG91bGQgdGhyb3cgaXQgb3V0LCBsaWtlbHkgcHJpb3IgdG8gYW55IHRpbWVvdXRzLg0KDQog 4oCUIEp1c3Rpbg0KDQpPbiBNYXkgMjUsIDIwMTcsIGF0IDEyOjIzIFBNLCBCcmlnIExhbW9yZWF1 eCA8QnJpZy5MYW1vcmVhdXhAbWljcm9zb2Z0LmNvbTxtYWlsdG86QnJpZy5MYW1vcmVhdXhAbWlj cm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KV2hhdCBpcyB0aGUgc3BlY2lmaWVkIHRpbWVv dXQgcGVyaW9kIHRvIGludmFsaWRhdGUgdGhlIHRva2VuPw0KDQpCcmlnIExhbW9yZWF1eA0KDQpE YXRhIFNvbHV0aW9uIEFyY2hpdGVjdA0KYnJpZy5sYW1vcmVhdXhAbWljcm9zb2Z0LmNvbTxtYWls dG86YnJpZy5sYW1vcmVhdXhAbWljcm9zb2Z0LmNvbT4NCjQ4MC04MjgtODcwNw0KVVMgRGVzZXJ0 L01vdW50YWluIFRlbXBlDQoNCg0KDQoNCjxpbWFnZTAwMS5qcGc+DQoNCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1h aWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmRhdGE9MDIlN0MwMSU3Q0JyaWcuTGFtb3JlYXV4JTQw bWljcm9zb2Z0LmNvbSU3QzUzODAyMDQyNWU4YTQxMWExMDY0MDhkNGFjZjZjYTMyJTdDNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjMyMzYyMzMyODIzMjE3MCZz ZGF0YT1VSFFPd2VnbTJrOE1iV1BDWUhSM2E0dGVkMzl4TUZsZmppbDRGZEpxeUE4JTNEJnJlc2Vy dmVkPTA+DQoNCg== --_000_DM5PR03MB292263A0429C2BEE01E95BB085CB0DM5PR03MB2922namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUki Ow0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlNlZ29lIFVJIFNlbWlib2xkIjsNCglwYW5vc2UtMToyIDExIDcgMiA0IDIgNCAyIDIg Mzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNv bm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UaGFua3MgZm9yIHRoZSByZXBseS4gSG93IGRvIHRoZSBSRkMgYWRkcmVzcyBhIHRva2Vu IHRoYXQgaGFzIGJlZW4gY29tcHJvbWlzZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1p dC5lZHVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSA2LCAyMDE3IDk6MTIgQU08 YnI+DQo8Yj5Ubzo8L2I+IEJyaWcgTGFtb3JlYXV4ICZsdDtCcmlnLkxhbW9yZWF1eEBtaWNyb3Nv ZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0O29hdXRoQGlldGYub3JnJmd0OyAmbHQ7b2F1 dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJGQyA3 MDA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0F1dGgg ZG9lc27igJl0IHNwZWNpZnkgYW5kIHNwZWNpZmljIHRpbWVvdXQgcGVyaW9kLCBpdOKAmXMgdXAg dG8gdGhlIEFTIHRoYXQgaXNzdWVzIHRoZSB0b2tlbiB0byBkZXRlcm1pbmUgaG93IGxvbmcgdGhl IHRva2VuIGlzIGdvb2QgZm9yLiBSRkM3MDA5IGlzbuKAmXQgYWJvdXQgdGltZW91dCBwZXJpb2Rz LCBpdOKAmXMgYWJvdXQgdGhlIGNsaWVudCBwcm9hY3RpdmVseSB0ZWxsaW5nIHRoZSBBUyB0aGF0 IGl0IGRvZXNu4oCZdA0KIG5lZWQgYSB0b2tlbiBhbnltb3JlIGFuZCB0aGUgQVMgc2hvdWxkIHRo cm93IGl0IG91dCwgbGlrZWx5IHByaW9yIHRvIGFueSB0aW1lb3V0cy48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1heSAyNSwg MjAxNywgYXQgMTI6MjMgUE0sIEJyaWcgTGFtb3JlYXV4ICZsdDs8YSBocmVmPSJtYWlsdG86QnJp Zy5MYW1vcmVhdXhAbWljcm9zb2Z0LmNvbSI+QnJpZy5MYW1vcmVhdXhAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCldoYXQgaXMg dGhlIHNwZWNpZmllZCB0aW1lb3V0IHBlcmlvZCB0byBpbnZhbGlkYXRlIHRoZSB0b2tlbj88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29sbGFwc2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0K PHRyIHN0eWxlPSJoZWlnaHQ6MTMuNXB0O2JyZWFrLWluc2lkZTogYXZvaWQiPg0KPHRkIHdpZHRo PSI0ODAiIGNvbHNwYW49IjIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NS4waW47cGFkZGlu ZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjEzLjVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU2VtaWJvbGQmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNTA1MDUwIj5CcmlnIExhbW9yZWF1eDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Imhl aWdodDo0Mi43NXB0O2JyZWFrLWluc2lkZTogYXZvaWQiPg0KPHRkIHdpZHRoPSIyMjgiIHZhbGln bj0idG9wIiBzdHlsZT0id2lkdGg6MTcxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWln aHQ6NDIuNzVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1MDUwNTAiPkRhdGEgU29sdXRpb24g QXJjaGl0ZWN0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1MDUwNTAiPjxhIGhyZWY9Im1haWx0bzpicmln LmxhbW9yZWF1eEBtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+Yjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29l IFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1NEY3MiI+cmlnLmxhbW9yZWF1eEBtaWNyb3Nv ZnQuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzUwNTA1MCI+NDgwLTgyOC04NzA3 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM1MDUwNTAiPlVTIERlc2VydC9Nb3VudGFpbiBUZW1wZTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNTA1MDUwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8dGQgd2lkdGg9IjM3OSIgc3R5bGU9 IndpZHRoOjI4NC4yNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDo0Mi43NXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImJyZWFrLWluc2lkZTogYXZvaWQi Pg0KPHRkIHdpZHRoPSIyMjgiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTcxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1MDUwNTAiPiZsdDtp bWFnZTAwMS5qcGcmZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L3RkPg0KPHRkIHdpZHRoPSIzNzkiIHN0eWxlPSJ3aWR0aDoyODQuMjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM5NTRGNzIiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0aCZhbXA7ZGF0YT0wMiU3QzAxJTdDQnJpZy5MYW1v cmVhdXglNDBtaWNyb3NvZnQuY29tJTdDNTM4MDIwNDI1ZThhNDExYTEwNjQwOGQ0YWNmNmNhMzIl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzIzNjIzMzI4 MjMyMTcwJmFtcDtzZGF0YT1VSFFPd2VnbTJrOE1iV1BDWUhSM2E0dGVkMzl4TUZsZmppbDRGZEpx eUE4JTNEJmFtcDtyZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5NTRGNzIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_DM5PR03MB292263A0429C2BEE01E95BB085CB0DM5PR03MB2922namp_-- From nobody Wed Jun 7 06:15:18 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68C0126E01 for ; Tue, 6 Jun 2017 15:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.484 X-Spam-Level: * X-Spam-Status: No, score=1.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uLjoFRbFlse for ; Tue, 6 Jun 2017 15:11:31 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0124.outbound.protection.outlook.com [104.47.40.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 5F3CE126D45 for ; Tue, 6 Jun 2017 15:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1lDM/+mkfjUvULUKEjvTK3kPIpcxHNn4GakFVPfC4WA=; b=Uz2qPM95ezRXnARnuIadldTWgI7l3yLsAXqYXz5V82hoG2tOFFiqXcVX2L/3AJ3JHNItYs1trQ5pDW6vPh5pjb2SOAgBZfShjmkViRT3YFjd/HwekXf7q32vx1BEe8catihddqYTrLxLdbxVNJumsK5wgelWVHowXynEcoFN5Wg= Received: from DM5PR03MB2922.namprd03.prod.outlook.com (10.175.106.20) by DM5PR03MB2921.namprd03.prod.outlook.com (10.175.106.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Tue, 6 Jun 2017 22:11:28 +0000 Received: from DM5PR03MB2922.namprd03.prod.outlook.com ([10.175.106.20]) by DM5PR03MB2922.namprd03.prod.outlook.com ([10.175.106.20]) with mapi id 15.01.1157.012; Tue, 6 Jun 2017 22:11:28 +0000 From: Brig Lamoreaux To: Justin Richer CC: "" Thread-Topic: [OAUTH-WG] RFC 7009 Thread-Index: AdLVcSY9VMwm5v7UR7a29hVsc2krjwJbn5+AAAt1W1AAADCqgAAAxENA Date: Tue, 6 Jun 2017 22:11:24 +0000 Deferred-Delivery: Tue, 6 Jun 2017 22:10:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [72.223.34.197] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR03MB2921; 7:F+eInEdGe9F79bNG9G0B0bXPMhR8Ptjngu06z8BKC+zuIldjF7LGR8lT7n4HEGPakMZeNZ+xvKM0lQYXFSRIJs/n2Pl5lBjClQ9PLnDWOrSDX3rCF1kx4t3ZK2YnwmE08KQT79IEW/PU6WBtAdKkpnhfwwV6AxHDBaNBkDUZhwQA9XwtZzynxwl+n871Z17fpnBgEARwgSVwPY5GYoSO4Ay1RB/PHFi1TU7lYLH7p7NWSAnN/5lXFM0MrXyX203CWG/La5qtMaVxClDQfARRF0BoAZQDujfDd7P9S3LaeI6ZYMavyXb640ee4ZC0oytAFO13gDX1h7ip903jOMr6uBSUBd9NhimO6ygmOhv88k4= x-ms-traffictypediagnostic: DM5PR03MB2921: x-ms-office365-filtering-correlation-id: 155f2b3c-3f2f-4516-2355-08d4ad28fb0f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR03MB2921; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721)(176510541525296)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR03MB2921; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR03MB2921; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39410400002)(39860400002)(39850400002)(39400400002)(24454002)(377454003)(53546009)(6916009)(6436002)(189998001)(606005)(7696004)(77096006)(6506006)(2950100002)(10090500001)(5005710100001)(110136004)(38730400002)(99286003)(72206003)(53936002)(966005)(6246003)(55016002)(2171002)(9686003)(10290500003)(54896002)(14454004)(236005)(25786009)(102836003)(6116002)(790700001)(4326008)(86362001)(3846002)(478600001)(6306002)(229853002)(81166006)(8676002)(8936002)(7736002)(74316002)(93886004)(50986999)(7906003)(5660300001)(6666003)(76176999)(54356999)(3280700002)(33656002)(2906002)(66066001)(122556002)(3660700001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR03MB2921; H:DM5PR03MB2922.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR03MB292236BB93A86422285D63DA85CB0DM5PR03MB2922namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 22:11:28.6421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2921 Archived-At: X-Mailman-Approved-At: Wed, 07 Jun 2017 06:15:09 -0700 Subject: Re: [OAUTH-WG] RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 22:11:34 -0000 --_000_DM5PR03MB292236BB93A86422285D63DA85CB0DM5PR03MB2922namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyB3aGVyZSB3ZSBoYXZlIHRoZSBxdWVzdGlvbiBhcm91bmQgdGltZW91dHMuIElmIHRo ZSBjbGllbnQgdGhpbmtzIGl0cyB0b2tlbiBpcyBjb21wcm9taXNlZCwgaG93IGxvbmcgc2hvdWxk IDcwMDkgdGFrZSB0byBpbnZhbGlkYXRlLg0KDQoNCg0KRnJvbTogSnVzdGluIFJpY2hlciBbbWFp bHRvOmpyaWNoZXJAbWl0LmVkdV0NClNlbnQ6IFR1ZXNkYXksIEp1bmUgNiwgMjAxNyAyOjQ2IFBN DQpUbzogQnJpZyBMYW1vcmVhdXggPEJyaWcuTGFtb3JlYXV4QG1pY3Jvc29mdC5jb20+DQpDYzog PG9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBSRkMgNzAwOQ0KDQoNCjcwMDkgZG9lc24ndCwgcmVhbGx5LiBJZiB0aGUgY2xpZW50IHRoaW5r cyBpdHMgdG9rZW4gaXMgY29tcHJvbWlzZWQsIGl0IGNhbiByZXZva2UgaXQgdXNpbmcgNzAwOS4g SWYgdGhlIHNlcnZlciBkZWNpZGVzIHRoZSB0b2tlbiBpcyBjb21wcm9taXNlZCwgaXQgaW52YWxp ZGF0ZXMgaXQgb24gaXRzIG93biwgbm90IGludm9sdmluZyA3MDA5LiBUaGUgY2xpZW50IGZpbmRz IG91dCB0aGUgdG9rZW4gaXNuJ3QgZ29vZCBhbnltb3JlIHRoZSBuZXh0IHRpbWUgaXQgdHJpZXMg dG8gdXNlIHRoZSB0b2tlbiAtLSBPQXV0aCBjbGllbnRzIGFsd2F5cyBuZWVkIHRvIGJlIHByZXBh cmVkIGZvciB0aGVpciB0b2tlbiBub3Qgd29ya2luZyBhdCBzb21lIHBvaW50LiBHb29kIG5ld3Mg aXMgdGhhdCB0aGUgcmVtZWR5IGZvciBoYXZpbmcgYSB0b2tlbiB0aGF0IGRvZXNuJ3Qgd29yayBp cyB0byBqdXN0IGRvIE9BdXRoIGFnYWluLg0KDQogLS0gSnVzdGluDQoNCk9uIDYvNi8yMDE3IDU6 NDMgUE0sIEJyaWcgTGFtb3JlYXV4IHdyb3RlOg0KVGhhbmtzIGZvciB0aGUgcmVwbHkuIEhvdyBk byB0aGUgUkZDIGFkZHJlc3MgYSB0b2tlbiB0aGF0IGhhcyBiZWVuIGNvbXByb21pc2VkPw0KDQpG cm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBtaXQuZWR1XQ0KU2VudDogVHVlc2Rh eSwgSnVuZSA2LCAyMDE3IDk6MTIgQU0NClRvOiBCcmlnIExhbW9yZWF1eCA8QnJpZy5MYW1vcmVh dXhAbWljcm9zb2Z0LmNvbT48bWFpbHRvOkJyaWcuTGFtb3JlYXV4QG1pY3Jvc29mdC5jb20+DQpD YzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxvYXV0aEBpZXRmLm9y Zz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUkZDIDcw MDkNCg0KT0F1dGggZG9lc27igJl0IHNwZWNpZnkgYW5kIHNwZWNpZmljIHRpbWVvdXQgcGVyaW9k LCBpdOKAmXMgdXAgdG8gdGhlIEFTIHRoYXQgaXNzdWVzIHRoZSB0b2tlbiB0byBkZXRlcm1pbmUg aG93IGxvbmcgdGhlIHRva2VuIGlzIGdvb2QgZm9yLiBSRkM3MDA5IGlzbuKAmXQgYWJvdXQgdGlt ZW91dCBwZXJpb2RzLCBpdOKAmXMgYWJvdXQgdGhlIGNsaWVudCBwcm9hY3RpdmVseSB0ZWxsaW5n IHRoZSBBUyB0aGF0IGl0IGRvZXNu4oCZdCBuZWVkIGEgdG9rZW4gYW55bW9yZSBhbmQgdGhlIEFT IHNob3VsZCB0aHJvdyBpdCBvdXQsIGxpa2VseSBwcmlvciB0byBhbnkgdGltZW91dHMuDQoNCiDi gJQgSnVzdGluDQoNCk9uIE1heSAyNSwgMjAxNywgYXQgMTI6MjMgUE0sIEJyaWcgTGFtb3JlYXV4 IDxCcmlnLkxhbW9yZWF1eEBtaWNyb3NvZnQuY29tPG1haWx0bzpCcmlnLkxhbW9yZWF1eEBtaWNy b3NvZnQuY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpXaGF0IGlzIHRoZSBzcGVjaWZpZWQgdGltZW91 dCBwZXJpb2QgdG8gaW52YWxpZGF0ZSB0aGUgdG9rZW4/DQoNCkJyaWcgTGFtb3JlYXV4DQoNCkRh dGEgU29sdXRpb24gQXJjaGl0ZWN0DQpicmlnLmxhbW9yZWF1eEBtaWNyb3NvZnQuY29tPG1haWx0 bzpicmlnLmxhbW9yZWF1eEBtaWNyb3NvZnQuY29tPg0KNDgwLTgyOC04NzA3DQpVUyBEZXNlcnQv TW91bnRhaW4gVGVtcGUNCg0KDQoNCg0KPGltYWdlMDAxLmpwZz4NCg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFp bG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmZGF0YT0wMiU3QzAxJTdDQnJpZy5MYW1vcmVhdXglNDBt aWNyb3NvZnQuY29tJTdDNTM4MDIwNDI1ZThhNDExYTEwNjQwOGQ0YWNmNmNhMzIlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzIzNjIzMzI4MjMyMTcwJnNk YXRhPVVIUU93ZWdtMms4TWJXUENZSFIzYTR0ZWQzOXhNRmxmamlsNEZkSnF5QTglM0QmcmVzZXJ2 ZWQ9MD4NCg0KDQo= --_000_DM5PR03MB292236BB93A86422285D63DA85CB0DM5PR03MB2922namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij5UaGlzIGlzIHdoZXJlIHdlIGhhdmUgdGhlIHF1ZXN0aW9uIGFyb3Vu ZCB0aW1lb3V0cy4gSWYgdGhlIGNsaWVudCB0aGlua3MgaXRzIHRva2VuIGlzIGNvbXByb21pc2Vk LCBob3cgbG9uZyBzaG91bGQgNzAwOSB0YWtlIHRvIGludmFsaWRhdGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bh bj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSnVzdGluIFJpY2hlciBbbWFpbHRvOmpy aWNoZXJAbWl0LmVkdV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDYsIDIwMTcg Mjo0NiBQTTxicj4NCjxiPlRvOjwvYj4gQnJpZyBMYW1vcmVhdXggJmx0O0JyaWcuTGFtb3JlYXV4 QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7 ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gUkZDIDcwMDk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD43MDA5IGRvZXNuJ3QsIHJl YWxseS4gSWYgdGhlIGNsaWVudCB0aGlua3MgaXRzIHRva2VuIGlzIGNvbXByb21pc2VkLCBpdCBj YW4gcmV2b2tlIGl0IHVzaW5nIDcwMDkuIElmIHRoZSBzZXJ2ZXIgZGVjaWRlcyB0aGUgdG9rZW4g aXMgY29tcHJvbWlzZWQsIGl0IGludmFsaWRhdGVzIGl0IG9uIGl0cyBvd24sIG5vdCBpbnZvbHZp bmcgNzAwOS4gVGhlIGNsaWVudCBmaW5kcyBvdXQgdGhlIHRva2VuIGlzbid0IGdvb2QgYW55bW9y ZSB0aGUgbmV4dA0KIHRpbWUgaXQgdHJpZXMgdG8gdXNlIHRoZSB0b2tlbiAtLSBPQXV0aCBjbGll bnRzIGFsd2F5cyBuZWVkIHRvIGJlIHByZXBhcmVkIGZvciB0aGVpciB0b2tlbiBub3Qgd29ya2lu ZyBhdCBzb21lIHBvaW50LiBHb29kIG5ld3MgaXMgdGhhdCB0aGUgcmVtZWR5IGZvciBoYXZpbmcg YSB0b2tlbiB0aGF0IGRvZXNuJ3Qgd29yayBpcyB0byBqdXN0IGRvIE9BdXRoIGFnYWluLjxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7LS0gSnVzdGluPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiA2LzYvMjAxNyA1OjQzIFBNLCBCcmlnIExhbW9yZWF1eCB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRo YW5rcyBmb3IgdGhlIHJlcGx5LiBIb3cgZG8gdGhlIFJGQyBhZGRyZXNzIGEgdG9rZW4gdGhhdCBo YXMgYmVlbiBjb21wcm9taXNlZD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKdXN0aW4g UmljaGVyIFs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5tYWlsdG86anJpY2hlckBt aXQuZWR1PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDYsIDIwMTcgOTox MiBBTTxicj4NCjxiPlRvOjwvYj4gQnJpZyBMYW1vcmVhdXggPGEgaHJlZj0ibWFpbHRvOkJyaWcu TGFtb3JlYXV4QG1pY3Jvc29mdC5jb20iPiZsdDtCcmlnLkxhbW9yZWF1eEBtaWNyb3NvZnQuY29t Jmd0OzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+ Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn Ij4NCiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb T0FVVEgtV0ddIFJGQyA3MDA5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T0F1dGggZG9lc27igJl0IHNwZWNpZnkgYW5kIHNwZWNpZmljIHRpbWVvdXQgcGVy aW9kLCBpdOKAmXMgdXAgdG8gdGhlIEFTIHRoYXQgaXNzdWVzIHRoZSB0b2tlbiB0byBkZXRlcm1p bmUgaG93IGxvbmcgdGhlIHRva2VuIGlzIGdvb2QgZm9yLiBSRkM3MDA5IGlzbuKAmXQgYWJvdXQg dGltZW91dCBwZXJpb2RzLCBpdOKAmXMgYWJvdXQgdGhlIGNsaWVudCBwcm9hY3RpdmVseSB0ZWxs aW5nIHRoZSBBUyB0aGF0IGl0IGRvZXNu4oCZdA0KIG5lZWQgYSB0b2tlbiBhbnltb3JlIGFuZCB0 aGUgQVMgc2hvdWxkIHRocm93IGl0IG91dCwgbGlrZWx5IHByaW9yIHRvIGFueSB0aW1lb3V0cy48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBK dXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1heSAyNSwgMjAxNywgYXQgMTI6MjMgUE0sIEJyaWcgTGFtb3JlYXV4ICZsdDs8YSBo cmVmPSJtYWlsdG86QnJpZy5MYW1vcmVhdXhAbWljcm9zb2Z0LmNvbSI+QnJpZy5MYW1vcmVhdXhA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCldoYXQgaXMgdGhlIHNwZWNpZmllZCB0aW1lb3V0IHBlcmlvZCB0byBpbnZhbGlkYXRl IHRoZSB0b2tlbj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29sbGFwc2U6Y29sbGFw c2UiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTMuNXB0O2JyZWFrLWluc2lkZTogYXZv aWQiPg0KPHRkIHdpZHRoPSI0ODAiIGNvbHNwYW49IjIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk dGg6NS4waW47cGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjEzLjVwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJyaWcgTGFtb3JlYXV4PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjQyLjc1cHQ7YnJlYWst aW5zaWRlOiBhdm9pZCI+DQo8dGQgd2lkdGg9IjIyOCIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0 aDoxNzEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDo0Mi43NXB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0Ij5EYXRhIFNvbHV0aW9uIEFyY2hpdGVjdDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTA1MDUwIj48YSBocmVm PSJtYWlsdG86YnJpZy5sYW1vcmVhdXhAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OiM5NTRGNzIiPmI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+cmlnLmxhbW9y ZWF1eEBtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij40ODAtODI4LTg3MDc8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5VUyBEZXNlcnQv TW91bnRhaW4gVGVtcGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv dGQ+DQo8dGQgd2lkdGg9IjM3OSIgc3R5bGU9IndpZHRoOjI4NC4yNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gMGluO2hlaWdodDo0Mi43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIg c3R5bGU9ImJyZWFrLWluc2lkZTogYXZvaWQiPg0KPHRkIHdpZHRoPSIyMjgiIHZhbGlnbj0idG9w IiBzdHlsZT0id2lkdGg6MTcxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jmx0O2ltYWdlMDAxLmpwZyZndDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8dGQgd2lkdGg9IjM3OSIgc3R5bGU9IndpZHRoOjI4NC4y NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1NEY3MiI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmFtcDtkYXRhPTAyJTdDMDElN0NCcmlnLkxh bW9yZWF1eCU0MG1pY3Jvc29mdC5jb20lN0M1MzgwMjA0MjVlOGE0MTFhMTA2NDA4ZDRhY2Y2Y2Ez MiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzMjM2MjMz MjgyMzIxNzAmYW1wO3NkYXRhPVVIUU93ZWdtMms4TWJXUENZSFIzYTR0ZWQzOXhNRmxmamlsNEZk SnF5QTglM0QmYW1wO3Jlc2VydmVkPTAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1NEY3MiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_DM5PR03MB292236BB93A86422285D63DA85CB0DM5PR03MB2922namp_-- From nobody Wed Jun 7 08:09:57 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AD4129471 for ; Wed, 7 Jun 2017 08:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx3HcvaBr4Y7 for ; Wed, 7 Jun 2017 08:09:53 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 E07A1128BA2 for ; Wed, 7 Jun 2017 08:09:52 -0700 (PDT) X-AuditID: 1209190c-699ff70000004228-da-5938173fc0cc 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 D9.23.16936.F3718395; Wed, 7 Jun 2017 11:09:51 -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 v57F9oXZ020546; Wed, 7 Jun 2017 11:09:51 -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 v57F9mck020896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jun 2017 11:09:49 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_61CEEF52-222B-4300-B99A-630FC7B77C6E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 7 Jun 2017 11:09:47 -0400 In-Reply-To: Cc: Brig Lamoreaux , "" To: Phil Hunt References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT17UXt4g0uDdR3eLMs9/MFiffvmKz WDC/kd2B2WPJkp9MHq07/rJ7fHx6iyWAOYrLJiU1J7MstUjfLoEr4+TRi4wFky8zVmz6u4Gp gXHeLsYuRk4OCQETiZ2zN7F2MXJxCAksZpK4fO8fO0hCSGADo0TnjACIxAMmiUltvawgCTYB VYnpa1qYQGxeASuJ7zN2AdkcHMwCSRLnj/KBmLwC+hK9z8HmCwsoSBxecpQZxGYRUJE40nsP LM4pYCdxbeZqsDizQLzEha/TwGwRoJpvV68zQqw9ySzx7+02NohDZSVuzb7EPIGRfxbCtlkI 22aBTdKWWLbwNTOErSmxv3s5C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka 6uVmluilppRuYgSFOqckzw7GM2+8DjEKcDAq8fBm7DGLFGJNLCuuzD3EKMnBpCTKW3DTPFKI Lyk/pTIjsTgjvqg0J7X4EKMEB7OSCK8fn0WkEG9KYmVValE+TEqag0VJnFdCozFCSCA9sSQ1 OzW1ILUIJivDwaEkwRsrBtQoWJSanlqRlplTgpBm4uAEGc4DNLwIpIa3uCAxtzgzHSJ/ilFR Spz3iyhQQgAkkVGaB9cLSkUJbw+bvmIUB3pFmDcHpJ0HmMbgul8BDWYCGsx3yQRkcEkiQkqq gTGWZ83rU1z/dl7pOj1FZq1Fvv3HtNtMabYtJqqsN9dMC91wb86+AycExcp3pDnyaNbd+fOm +fvO8+oeLK5REvyJesJ9O15O6vSTWd+pfkQz5UXGvqzzyo3VqmK3dFnXT2CVYEj7OpfX2vX9 koXtQTPVUtUPtk7mazva4bkqs6TA7FZN/lu/t0osxRmJhlrMRcWJAGFDLnkgAwAA Archived-At: Subject: Re: [OAUTH-WG] RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 15:09:56 -0000 --Apple-Mail=_61CEEF52-222B-4300-B99A-630FC7B77C6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agree, and this was discussed at the time of 7662=E2=80=99s ratification = but there was no agreement on a delivery mechanism. I=E2=80=99d like to = see a SECEVENT with a 7662 payload, which would take care of a large = number of use cases, including =E2=80=9Ctoken revoked=E2=80=9D and = =E2=80=9Cnew token issued=E2=80=9D being delivered downstream to RS=E2=80=99= s. It=E2=80=99s a good compliment to the callback-based mechanism in = 7662. =E2=80=94 Justin > On Jun 6, 2017, at 6:31 PM, Phil Hunt (IDM) = wrote: >=20 > This is why i expect a secevent token revocation event to be defined = to complement 7009 once secevents moves further along.=20 >=20 > We want to be able to know in near real time when a token is revoked = to avoid constant checks to see if a token is still good.=20 >=20 > Phil >=20 > On Jun 6, 2017, at 3:18 PM, Justin Richer > wrote: >=20 >> That really depends on the nature of your tokens and how you manage = their internal validity. It=E2=80=99s really as soon as possible, = isn=E2=80=99t it? If you can invalidate it immediately, do that. In our = implementation, we delete it from the data store as soon as the = revocation request comes in, which invalidates it. Downstream RS=E2=80=99s= might have cached introspection (RFC7662) results so they=E2=80=99ll = find out once their caches expire. If you=E2=80=99ve got some other = synchronization method that takes some time to propagate, then that=E2=80=99= s going to be the answer. All of this is dependent on your = implementation and not on the revocation protocol, but in all cases I = see no reason to *wait* any amount of time to revoke a token that=E2=80=99= s been requested for revocation by a client, for any reason. The client = is effectively saying =E2=80=9Cif you see this token again it isn=E2=80=99= t from me=E2=80=9D, which should be a good enough indication to throw it = out as soon as possible. >>=20 >> This all falls apart if you=E2=80=99re using self-contained tokens = =E2=80=94 there=E2=80=99s not a good way to invalidate a self-contained = token without using some kind of lookup service. RFC7662 defines such a = service for OAuth, but then your tokens aren=E2=80=99t really fully = self-contained anymore and you=E2=80=99re simply stuck waiting for the = compromised token to expire. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux = > = wrote: >>>=20 >>> This is where we have the question around timeouts. If the client = thinks its token is compromised, how long should 7009 take to = invalidate. >>> =20 >>> =20 >>> =C2=A0 <> >>> From: Justin Richer [mailto:jricher@mit.edu = ]=20 >>> Sent: Tuesday, June 6, 2017 2:46 PM >>> To: Brig Lamoreaux > >>> Cc: > > >>> Subject: Re: [OAUTH-WG] RFC 7009 >>> =20 >>> 7009 doesn't, really. If the client thinks its token is compromised, = it can revoke it using 7009. If the server decides the token is = compromised, it invalidates it on its own, not involving 7009. The = client finds out the token isn't good anymore the next time it tries to = use the token -- OAuth clients always need to be prepared for their = token not working at some point. Good news is that the remedy for having = a token that doesn't work is to just do OAuth again. >>>=20 >>> -- Justin >>>=20 >>> =20 >>> On 6/6/2017 5:43 PM, Brig Lamoreaux wrote: >>> Thanks for the reply. How do the RFC address a token that has been = compromised? >>> =20 >>> From: Justin Richer [mailto:jricher@mit.edu = ]=20 >>> Sent: Tuesday, June 6, 2017 9:12 AM >>> To: Brig Lamoreaux = >>> Cc: = >>> Subject: Re: [OAUTH-WG] RFC 7009 >>> =20 >>> OAuth doesn=E2=80=99t specify and specific timeout period, it=E2=80=99= s up to the AS that issues the token to determine how long the token is = good for. RFC7009 isn=E2=80=99t about timeout periods, it=E2=80=99s = about the client proactively telling the AS that it doesn=E2=80=99t need = a token anymore and the AS should throw it out, likely prior to any = timeouts. >>> =20 >>> =E2=80=94 Justin >>> =20 >>> On May 25, 2017, at 12:23 PM, Brig Lamoreaux = > = wrote: >>> =20 >>> Hi, >>>=20 >>> What is the specified timeout period to invalidate the token? >>> =20 >>> Brig Lamoreaux >>> Data Solution Architect >>> brig.lamoreaux@microsoft.com >>> 480-828-8707 >>> US Desert/Mountain Tempe >>> =20 >>> =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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1= 0&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D7yMIczBrZnmQ14Nkf4MB= GaIHnxRyiLGXB1Xhuxp1Ur0&s=3DTaKHdPgtEPkCV_YuOHlkoXRZJjf0k8Y4-yowD3YbhPw&e=3D= = =20 --Apple-Mail=_61CEEF52-222B-4300-B99A-630FC7B77C6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agree, and this was discussed at the time of 7662=E2=80=99s = ratification but there was no agreement on a delivery mechanism. I=E2=80=99= d like to see a SECEVENT with a 7662 payload, which would take care of a = large number of use cases, including =E2=80=9Ctoken revoked=E2=80=9D and = =E2=80=9Cnew token issued=E2=80=9D being delivered downstream to RS=E2=80=99= s. It=E2=80=99s a good compliment to the callback-based mechanism in = 7662.

 =E2=80=94 = Justin

On Jun 6, 2017, at 6:31 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

This is why i = expect a secevent token revocation event to be defined to complement = 7009 once secevents moves further along. 

We want to be able to know in near real = time when a token is revoked to avoid constant checks to see if a token = is still good. 

Phil

On Jun 6, 2017, at 3:18 PM, Justin Richer = <jricher@mit.edu> = wrote:

That really depends on the nature of your = tokens and how you manage their internal validity. It=E2=80=99s really = as soon as possible, isn=E2=80=99t it? If you can invalidate it = immediately, do that. In our implementation, we delete it from the data = store as soon as the revocation request comes in, which invalidates it. = Downstream RS=E2=80=99s might have cached introspection (RFC7662) = results so they=E2=80=99ll find out once their caches expire. If = you=E2=80=99ve got some other synchronization method that takes some = time to propagate, then that=E2=80=99s going to be the answer. All of = this is dependent on your implementation and not on the revocation = protocol, but in all cases I see no reason to *wait* any amount of time = to revoke a token that=E2=80=99s been requested for revocation by a = client, for any reason. The client is effectively saying =E2=80=9Cif you = see this token again it isn=E2=80=99t from me=E2=80=9D, which should be = a good enough indication to throw it out as soon as possible.

This all falls apart if = you=E2=80=99re using self-contained tokens =E2=80=94 there=E2=80=99s not = a good way to invalidate a self-contained token without using some kind = of lookup service. RFC7662 defines such a service for OAuth, but then = your tokens aren=E2=80=99t really fully self-contained anymore and = you=E2=80=99re simply stuck waiting for the compromised token to = expire.

 =E2=80=94 Justin

On Jun = 6, 2017, at 6:11 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> wrote:

This is where we have the question around = timeouts. If the client thinks its token is compromised, how long should = 7009 take to invalidate.
 
 
From: Justin Richer [mailto:jricher@mit.edu] 
Sent: Tuesday, June 6, 2017 2:46 = PM
To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] RFC 7009
 

7009 doesn't, = really. If the client thinks its token is compromised, it can revoke it = using 7009. If the server decides the token is compromised, it = invalidates it on its own, not involving 7009. The client finds out the = token isn't good anymore the next time it tries to use the token -- = OAuth clients always need to be prepared for their token not working at = some point. Good news is that the remedy for having a token that doesn't = work is to just do OAuth again.

 -- Justin

 
On 6/6/2017 5:43 PM, Brig Lamoreaux = wrote:
Thanks for the reply. How do the RFC address a = token that has been compromised?
 
From: Justin Richer [mailto:jricher@mit.edu] 
Sent: Tuesday, June 6, 2017 9:12 = AM
To: Brig Lamoreaux <Brig.Lamoreaux@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] RFC = 7009
 
OAuth doesn=E2=80=99t specify and specific timeout = period, it=E2=80=99s up to the AS that issues the token to determine how = long the token is good for. RFC7009 isn=E2=80=99t about timeout periods, = it=E2=80=99s about the client proactively telling the AS that it = doesn=E2=80=99t need a token anymore and the AS should throw it out, = likely prior to any timeouts.
 
 =E2=80=94 Justin
 
On May 25, 2017, at 12:23 PM, Brig Lamoreaux <Brig.Lamoreaux@microsoft.com> wrote:
 
Hi,

What is the specified timeout period to = invalidate the token?
 
Brig Lamoreaux
Data Solution = Architect
brig.lamoreaux@microsoft.com
480-828-8707
US Desert/Mountain = Tempe
 
 
<image001.jpg>
 
 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQc= xBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&a= mp;m=3D7yMIczBrZnmQ14Nkf4MBGaIHnxRyiLGXB1Xhuxp1Ur0&s=3DTaKHdPgtEPkCV_Y= uOHlkoXRZJjf0k8Y4-yowD3YbhPw&e=3D

= --Apple-Mail=_61CEEF52-222B-4300-B99A-630FC7B77C6E-- From nobody Fri Jun 9 16:39:36 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C436124D6C; Fri, 9 Jun 2017 16:39:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149705157458.2465.8912240257770601530@ietfa.amsl.com> Date: Fri, 09 Jun 2017 16:39:34 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 23:39:35 -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 of the IETF. Title : OAuth 2.0 for Native Apps Authors : William Denniss John Bradley Filename : draft-ietf-oauth-native-apps-12.txt Pages : 21 Date : 2017-06-09 Abstract: OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 9 16:40:52 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150CF126C89 for ; Fri, 9 Jun 2017 16:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PON9PfcQcfql for ; Fri, 9 Jun 2017 16:40:44 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 795D31200FC for ; Fri, 9 Jun 2017 16:40:44 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m47so4253419iti.0 for ; Fri, 09 Jun 2017 16:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FdSp0dnomx4P7S3dDr6wYl6IY5ijZsnbpNPt5KvYdXE=; b=rU4OX+UIKleTNs4Vk1UR31abjt7IOHTkMhc8NlxC7Abc493Jx5BQWAtnl9HUusYFZl Hsdj20zQm5nMxWXJhXDf6e2hRA73g8rU/Gmrvxe2Ta5Zial2sJZarO7Iw7oXbcv4lkG6 cy/yURVHrMHvJWyhdM9+AwBMzNaNYPMHbwAE4PNr/EKOzym+BG9xlq3dWQ1CfU/3MYOx ClTUaRcjwIhAm4+/ktfdbTQkiswjdtExZPbNzisGalLmyks8+lX67jcj6HGmkdOKAMEf lDSfy98wig5TXHoXJ7rNbQ90gFK13md4aicaT/IQvfNKE3us83E093yBfgsXliy5AKT9 7MvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FdSp0dnomx4P7S3dDr6wYl6IY5ijZsnbpNPt5KvYdXE=; b=bJXJp0KoS+0Br6mOz9mfvDJkEW7wXkhnmn80I67VLFNco9Q4VpRDYMDiWnrPO2k6u9 4CiLgANjZ+6BBqhScrhUexqnbdvDFGfxq4b69IZXStcabVd1uOu++tXVR7G7uqJCS15v 6Z84/cZWmTybmnVCqaIK0zOc1mANlDlzNxhXYvV6iPkCfntOWW0f0zuuhy5XG2zu4Doh mEbimJweXsNRdWj164GJtYzLOjzObhVa3/FbcC6ycTYrvBj512sireOQaQjUK8ZmOWpk QeRrVBrheLxtKIShaYMb/Z6ULe+sawCu0JFVonDH242k/8/U4a2diKkpcHDxZ8uyX/XI AbTA== X-Gm-Message-State: AKS2vOwSSZeDaRrEHRcqs599V7Hmwo6MCMLuTv7cZGSwPOnkjSyrLNIS Nd/IzTtRQVRga2XjrH+OQiiHXxkOOpgf X-Received: by 10.107.5.76 with SMTP id 73mr2856579iof.182.1497051639128; Fri, 09 Jun 2017 16:40:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.41.1 with HTTP; Fri, 9 Jun 2017 16:40:18 -0700 (PDT) In-Reply-To: <149557608311.28484.15294343372018912184.idtracker@ietfa.amsl.com> References: <149557608311.28484.15294343372018912184.idtracker@ietfa.amsl.com> From: William Denniss Date: Fri, 9 Jun 2017 16:40:18 -0700 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a113ef74829966905518f7f65" Archived-At: Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 23:40:46 -0000 --001a113ef74829966905518f7f65 Content-Type: text/plain; charset="UTF-8" Thank you for your review. We've reworked section 8.7 to move the focus away from the user regarding mitigations for apps that fake external user-agents. On Tue, May 23, 2017 at 2:48 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-oauth-native-apps-11: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Adam's general sentiment about detection of bad behavior vs > asking people not to be bad. > > -8 and it's children: There seems to be a lot of duplication (including > duplication of normative language) between the security considerations > and the rest of the document. > > - 8.7: This section seems to argue against using in-app browser tabs in > the first place. If there is no good way for the user to tell the > difference between that and an imbedded UA, then maybe we should train > users to be suspicious of any in-app presentation of the authorization > request? The last paragraph seems to be founded on a mismatch between > user needs and typical user sophistication. > > > Re-worked this section a lot with a focus on actionable steps that authorization servers and app stores can take. Also covers some "detection of bad behavior". --001a113ef74829966905518f7f65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your review.

We've re= worked section 8.7 to move the focus away from the user regarding mitigatio= ns for apps that fake external user-agents.

On Tue, May 23, 2017 at 2:48 PM, Ben C= ampbell <ben@nostrum.com> wrote:
Ben Campbell has entered the following ballot posit= ion for
draft-ietf-oauth-native-apps-11: No Objection

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I agree with Adam's general sentiment about detection of bad behavior v= s
asking people not to be bad.

-8 and it's children: There seems to be a lot of duplication (including=
duplication of normative language) between the security considerations
and the rest of the document.

- 8.7: This section seems to argue against using in-app browser tabs in
the first place. If there is no good way for the user to tell the
difference between that and an imbedded UA, then maybe we should train
users to be suspicious of any in-app presentation of the authorization
request? The last paragraph seems to be founded on a mismatch between
user needs and typical user sophistication.



Re-worked this section a lot with a fo= cus on actionable steps that authorization servers and app stores can take.= =C2=A0 Also covers some "detection of bad behavior".
= =C2=A0

--001a113ef74829966905518f7f65-- From nobody Fri Jun 9 16:44:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E1812741D for ; Fri, 9 Jun 2017 16:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvW74dm-zJSs for ; Fri, 9 Jun 2017 16:44:55 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D117127180 for ; Fri, 9 Jun 2017 16:44:55 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m62so4491911itc.0 for ; Fri, 09 Jun 2017 16:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7T8LLkDgiSt8Bq+NPFVDUDEHvSoiEIRWhLF171GkAJE=; b=YxGDwGpVaM8mZ5kVQUIZLVCPf+ntivL0skssmyY16t7G9Oiq3cSke+nLiEpW/0mxXN hmZKYAEmrwmy6fIO5F+9oF4y05MX4RT6TBVlJt1+EWqdoiHHefrKwpaJRw6t/nGvC81z uKYqw7ROSyv16gWO+47G+RM96M2BA6LNi6VnG+6Liko2ba2b1lFwPzjUMZAYiBB3vSKW 5gpJpOTajqDsTNhohEqMmFJrPOhk+uwTV8DEigfUIignfQI/v0PAJYjD9KK8PbTuYebk jHJS3IU2JCp7qx7DAB8GKokybWmAKSc+/1yUOpoeyzhaLiwvaxH1Q66e+CpfN7hxq4et z3uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7T8LLkDgiSt8Bq+NPFVDUDEHvSoiEIRWhLF171GkAJE=; b=fJKNWD2eGzJedQZol6YQRlq/GYGMcA6rLjr71ZvvzqefaRKsu3NlGDw65utkC3t/D+ 3VgBpHebgX8mW3Xcb+FuVkhpTWjK9XP4in8mkIKCfjL69UjkxnKpU6I6BX9hT9gdIc4Y Kop4vmOM8SGJwsTKUsWp/PdUqTmVv573KdUronyHb1mKgyAtA99uKQcEDeoZF1Js+Ksn iTkzVdWJF/nCrfl1zp+W2Nqa0bwbS6xzdMjN2DfBxDwPrwSluUojSZS+mMGpoFmxD7hq tCKayCTridZNwoDWFKPOu0ZKq+gKoC3obpfJfNg1fSoDHMkHINfJDt/PjA5RXCbd0AzV EiVA== X-Gm-Message-State: AODbwcAkdREpKkNbIj81Gx64IBQ/DkM+92b1l+xCppfHnR8TZ0HgG957 boTgJrxdMxeiQv6Lo1LJ38RJWMcskypX X-Received: by 10.36.204.69 with SMTP id x66mr2174861itf.101.1497051894772; Fri, 09 Jun 2017 16:44:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.41.1 with HTTP; Fri, 9 Jun 2017 16:44:34 -0700 (PDT) In-Reply-To: <6823ceb2-03cc-606a-1841-5924840389d4@nostrum.com> References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> <6823ceb2-03cc-606a-1841-5924840389d4@nostrum.com> From: William Denniss Date: Fri, 9 Jun 2017 16:44:34 -0700 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c057fba667d7505518f8ea7" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 23:44:58 -0000 --94eb2c057fba667d7505518f8ea7 Content-Type: text/plain; charset="UTF-8" Thanks Adam for your feedback, and reviewing the work in progress! v12 is out now with those and other IESG review related changes. On Fri, Jun 2, 2017 at 8:01 PM, Adam Roach wrote: > On 6/2/17 21:25, William Denniss wrote: > > In my staged copy > , > I have followed your advice and reversed the recommendation ordering, and > mentioned the caveats that the user's personalisations are not present in > the broker. The lack of password manager support is a very good point. It's > definitely been one of the advantages we've seen by moving to browsers from > web-view. > > > Thanks! The new text in the Windows section looks great. > > /a > --94eb2c057fba667d7505518f8ea7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Adam for your feedback, and reviewing the work in p= rogress! v12 is out now with those and other IESG review= related changes.

= On Fri, Jun 2, 2017 at 8:01 PM, Adam Roach <adam@nostrum.com>= wrote:
=20 =20 =20
On 6/2/17 21:25, William Denniss wrote:
In my staged copy= , I have followed your advice and reversed the recommendation ordering, and mentioned the caveats that the user's personalisations are not present in the broker. The lack of password manager support is a very good point. It's definitely been one of the advantage= s we've seen by moving to browsers from web-view.

 Thanks! The new text in the Windows section looks great.

/a

--94eb2c057fba667d7505518f8ea7-- From nobody Fri Jun 9 16:55:45 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF2B120454 for ; Fri, 9 Jun 2017 16:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0buJAHJDRdzp for ; Fri, 9 Jun 2017 16:55:43 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 E74C2124D6C for ; Fri, 9 Jun 2017 16:55:40 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id d14so9656758qkb.1 for ; Fri, 09 Jun 2017 16:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8QS+Of3kQllS6Fq+wLzDMvy+5ORH6WcIT+MYThxLSBI=; b=zgIyDp6XoncuaECeN8nQ9TI9B+RgxU9MuQMjK36CCuTauuJ2oOWY4JhMMkPQwsfX0N gEnUCyPYO77uZlJEWwG0CaBVRXw9t7Nvx31CXzwD+y2HLnYMiWPT8HB76zjB1Imuqw52 RLM7McJ8bnd/DVLt7YfXp4eprUKi3matG/NMpcmEQf8ADCB2iaD6LnCCE6tS7j/1hWxZ ZLiSTS+oCUmN21dJaqYaCFkUA4BHwKvye4nEK+NUzb5sz2CXeUHuXd1IM+b6qIOTboQk Uc6L4RBVKJeCLGkvEgLDsxdV9tU+tVp9S4learsxsr8Qr2bYx1PyUS1pdPmesLDvP6hI XY1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8QS+Of3kQllS6Fq+wLzDMvy+5ORH6WcIT+MYThxLSBI=; b=VUJxW4YeEVIdKpmVJ0G1yRuKi1s24wW1ceInb93XkRlNfh+iC18RjRWQPMAx7F4NG6 848BlJRBIRQHOSbAIdpcDYt2Tgw6TDQmJbpYcoXd6lkoCMt+sSip7P7M8Hhw37tSbjUn 38biUWA0qtxa44+IxgbQbTfKDZpDpkf5p6abSrCsgS7UuFxcIZwE9ZwTMTJqAiPM4IKv NVq5GyVWXZBb5e58KrZ+L8WMolDG2WRCYV2nMzSufrevxhAqUyYMxVoYApYR5VUkSKLc 4F6uzOnqXWYyXgIIdyCiHadtWGKso3XUFo/dvjyZDHm8BiuGVY5tQntAq6flAjTEZAl8 9gzw== X-Gm-Message-State: AKS2vOwCNFwqEWQ8S9Rn5glPs2e6XMGq3p2e0LHlLWOKKj8PJ/Hr2+ZH hHtmkAG9yJ9P1NHx X-Received: by 10.55.162.196 with SMTP id l187mr57928104qke.182.1497052539978; Fri, 09 Jun 2017 16:55:39 -0700 (PDT) Received: from [192.168.8.100] ([181.201.176.188]) by smtp.gmail.com with ESMTPSA id 8sm1683118qki.40.2017.06.09.16.55.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 16:55:39 -0700 (PDT) From: John Bradley Message-Id: <4C2CE005-FBC5-4F49-B08A-8A1EADBFE9BF@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 9 Jun 2017 19:55:35 -0400 In-Reply-To: <6823ceb2-03cc-606a-1841-5924840389d4@nostrum.com> Cc: William Denniss , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, "oauth@ietf.org" To: The IESG References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> <6823ceb2-03cc-606a-1841-5924840389d4@nostrum.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114d7148de7d2c05518fb4cd" Archived-At: Subject: [OAUTH-WG] IESG Comments addressed X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 23:55:45 -0000 --001a114d7148de7d2c05518fb4cd Content-Type: multipart/alternative; boundary="Apple-Mail=_66F58535-664F-474F-ACBB-D9F597C8B106" --Apple-Mail=_66F58535-664F-474F-ACBB-D9F597C8B106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Authors have published a new draft (12) of = draft-ietf-oauth-native-apps. We believe that all IESG comments have now been addressed. Let us know if anything else is required on our side to progress the = document to the RFC Editor. Regards John B.= --Apple-Mail=_66F58535-664F-474F-ACBB-D9F597C8B106 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The Authors have published a new draft (12) of draft-ietf-oauth-native-apps.

We believe that all IESG comments have now been = addressed.

Let us know if anything = else is required on our side to progress the document to the RFC = Editor.

Regards
John B.
= --Apple-Mail=_66F58535-664F-474F-ACBB-D9F597C8B106-- --001a114d7148de7d2c05518fb4cd Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIApHfD0vJ4sxnU5lpXM3CN/U8OKr NXYreYr2iK+io4iYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDYwOTIzNTU0MFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBufIfPxKYOQo5SR20J/bDdi2b2HtAQ7I5vh8JvepY/6VfP zJVxACx3SCmaaWkk/U1vs8iL32ewWKP4cEZOOba8PoTEy7BZMjwrGu7dfk6TxRZceNhSmiVxT3qZ mX9aupBIHuSFQk5DI1xCFspojSlfm4gwI8+e5K0tPTZrI0MRlfauD3o4eoMClTgxZapS4mXzkUwh r+zHimxo1CBtQecVuDUPssRFmiqPnvIDUQCMdpwjyeh7dYQOVrdQ5/pT9ZYr8SaTwuXt9wZxKrsj 7hPZZCcXflhrqwCV1nC4yOEd7phkAjJQFngNEZ+AIO+zxAKYNJe+zyE006Od0g4Hb6np --001a114d7148de7d2c05518fb4cd-- From nobody Sun Jun 11 20:53:02 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB2F129B9E for ; Sun, 11 Jun 2017 20:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igC4RoZtznPF for ; Sun, 11 Jun 2017 20:52:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A051270A0 for ; Sun, 11 Jun 2017 20:52:58 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AED405D68D for ; Mon, 12 Jun 2017 03:52:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AED405D68D Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bburke@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com AED405D68D Received: from ovpn-116-70.phx2.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3AD0417BB0 for ; Mon, 12 Jun 2017 03:52:57 +0000 (UTC) To: oauth@ietf.org From: Bill Burke Message-ID: Date: Sun, 11 Jun 2017 23:52:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 12 Jun 2017 03:52:57 +0000 (UTC) Archived-At: Subject: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 03:53:01 -0000 Has anybody done any spec work around doing oauth from command line interfaces? We're looking for something where the auth server can generate text-based challenges that are rendered in the console window that query for simple text input over possibly multiple requests. I'm not talking about Resource Owner or Client Credentials grant. The command line client may not know the credential types required for a successful token request. It would be easy to write a simple protocol, but I'd rather just do something around any existing internet draft or rfc that somebody has put some thought into. Hope I'm making sense here. Thanks, Bill Burke Red Hat From nobody Sun Jun 11 20:58:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3235F129BA8 for ; Sun, 11 Jun 2017 20:58:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHBd8_cCD-wB for ; Sun, 11 Jun 2017 20:58:21 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33170129BA5 for ; Sun, 11 Jun 2017 20:58:21 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id l89so46862637pfi.2 for ; Sun, 11 Jun 2017 20:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9nDdXrWs+kQXxXbQ63x3UPP6BsT/6EDOfZISuARVb+w=; b=H2oZCNgdtZam0emggV8w6+E0vwqQLWVSIlrLkf1rTBowItV0QYvJqwe6uAqdexvxog N9qzKcWzRkUhyTgtwQijrEWMUQ1uVnhOY0kBQoJdx5ibripm26J1lWcPRfpc4ZqS3vt9 /bnpZIZt6J14WUNdD/RMKFDER4eRvxx4VQTE7PzomdZeQnvEEzV81LcgEYVwI5wutMkZ Bmdrma9ipwOyK/YnpMHLwEZ9mp/I3XczlU7Dm3C3ImwGVmJQNnlz9wDX9rykCkZeSRcs xu8iVL4fvY3V6Gs/1S4OOnKbtIRA6uyvDvpsBsNKpG5cbepLocz6lB1k2HLGDKEMiJo9 qGpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9nDdXrWs+kQXxXbQ63x3UPP6BsT/6EDOfZISuARVb+w=; b=Z7Ma8jTxi5TY7UrtM3/uKrrh8pkvNq4BzPkkUyr7i5InEtjIWQAWel/sTCl+p5WD2y Q+GUNC8ZAbNJ7qacQ06JmuECiU3wgTChBI+D5yoGkJDtYKDoJoWlRzKV7XtBP7SaCFlw /df5VqKb0VmVCRrb+asS3CobesyABHFM6Z4wXFkXF9maewfuQUSfF+LhPrmwR/0qoYh8 ss0n9j5tqUeecrTt8MsxFGtS25oj8o4CpKRLdOiZFyAFl3DczpBydgWSjf62CcU9ia4B +2t7Aw1utl32vVw6ab4fYq0rK06P+ja/cd06ee8LJjXhXzwPj1A15Bsr4u5GSdU8yJEz 89vQ== X-Gm-Message-State: AODbwcB++yXaU1p4Y34fqg7v53zdOmRDlU/tljIif8hESgQd76XsIzlV AYJF4NH7NDfvxpEYHcHkdw== X-Received: by 10.99.67.69 with SMTP id q66mr55371069pga.156.1497239900594; Sun, 11 Jun 2017 20:58:20 -0700 (PDT) Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com. [209.85.192.179]) by smtp.gmail.com with ESMTPSA id u45sm21492836pgn.28.2017.06.11.20.58.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 20:58:19 -0700 (PDT) Received: by mail-pf0-f179.google.com with SMTP id 83so46864783pfr.0 for ; Sun, 11 Jun 2017 20:58:19 -0700 (PDT) X-Received: by 10.99.49.206 with SMTP id x197mr54780986pgx.181.1497239899529; Sun, 11 Jun 2017 20:58:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.67 with HTTP; Sun, 11 Jun 2017 20:58:19 -0700 (PDT) In-Reply-To: References: From: Aaron Parecki Date: Sun, 11 Jun 2017 20:58:19 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bill Burke Cc: OAuth WG Content-Type: multipart/alternative; boundary="94eb2c115d705aedd70551bb54a6" Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 03:58:23 -0000 --94eb2c115d705aedd70551bb54a6 Content-Type: text/plain; charset="UTF-8" I've seen this done a few ways: * The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device. * I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal. * The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user. ---- Aaron Parecki aaronparecki.com @aaronpk On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke wrote: > Has anybody done any spec work around doing oauth from command line > interfaces? We're looking for something where the auth server can generate > text-based challenges that are rendered in the console window that query > for simple text input over possibly multiple requests. I'm not talking > about Resource Owner or Client Credentials grant. The command line client > may not know the credential types required for a successful token request. > It would be easy to write a simple protocol, but I'd rather just do > something around any existing internet draft or rfc that somebody has put > some thought into. Hope I'm making sense here. > > Thanks, > > Bill Burke > > Red Hat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c115d705aedd70551bb54a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've seen this done a few ways:

* The Device Flow:=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-device-fl= ow which is what you see on browserless devices like the Apple TV loggi= ng in to a cable provider from your phone. A short code is generated and di= splayed on the screen, you launch a browser on your phone and enter the cod= e. This would work just as well from the command line on the same device.* I've also seen apps use the authorization flow, by displaying the = authorization URL on the command line prompt and instructing the user to op= en it in a browser. The redirect URI is a hosted web page that displays the= authorization code and instructs the user to paste it back at the terminal= .
* The command line app can launch an HTTP server on localhost a= nd use that as the redirect URL for the authorization code flow. This optio= n ends up being the most seamless since it works like a traditional flow wi= thout any special instructions to the user.

----
Aaron Parecki
=


On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke = <bburke@redhat.com> wrote:
Has anybody done any spec work around doing oauth from command line interf= aces?=C2=A0 We're looking for something where the auth server can gener= ate text-based challenges that are rendered in the console window that quer= y for simple text input over possibly multiple requests.=C2=A0 I'm not = talking about Resource Owner or Client Credentials grant.=C2=A0 The command= line client may not know the credential types required for a successful to= ken request. It would be easy to write a simple protocol, but I'd rathe= r just do something around any existing internet draft or rfc that somebody= has put some thought into.=C2=A0 Hope I'm making sense here.

Thanks,

Bill Burke

Red Hat

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

--94eb2c115d705aedd70551bb54a6-- From nobody Mon Jun 12 04:33:31 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC7912E05D for ; Mon, 12 Jun 2017 04:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtGj3Z9dzJsi for ; Mon, 12 Jun 2017 04:33:27 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 1FF1512E052 for ; Mon, 12 Jun 2017 04:33:27 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id o9so26139126yba.3 for ; Mon, 12 Jun 2017 04:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=oHoKr8d6l8Dl63lf8QLsUN2bv6PL6M8DGoB4WsRMVLM=; b=B2gk3edEovhw4aWTX991LTcZRJOTh3/petCzHR5Bgk8v/8sb/o381MdZN2tqT43vhb Q1wmwDSdkCe6bPvOqmixgFKA+LfSCF8VBQoJvAysWwZmNP6UfJdSvvsnnwILF2OGiVHu LOkW+gUPLLYKku6hN6jB+Pw6++AjQf1adIgq3l/KoI1k/IfFPK8Ie5j9WbJcwk7joi8i tEFPOdN91o0s8neF1IqoI1IxOEybU+iJQm3PTs+Zq5qh4o2S0YUVpcmpMCZTh4PQkzjW L8w1c15Ob0Mgo5vYNayz47gu9023ak4DX9F3278gxpQlSbqANNor1WC0+S9eoKq5iZYq klKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=oHoKr8d6l8Dl63lf8QLsUN2bv6PL6M8DGoB4WsRMVLM=; b=Ut5jAtRfeUG/FucVxRBJEZ2RioTIzjBI9rEOL56mpLditcutFhDfsEO+pnkUbGJI+p m/AQTplYuSuOM5RsDYYRMXrlqts84zSyUMPuyYWaH+G/jlENHk1DXrl1c9S2TuP6GA3a JDIpRzTZn3/FTIDQvmrVDAksUiN2+MSBIyETfSNJRNSPRyI6++SCovy3Mta3BTucYe0e vcv2M8FTRLBgD8RxfC85Ufz0jkxlyuBGlHAWqnr/LtYX28gh9wWNipTvdJYS7+H61KLt S36WVQCGWfaVfGp3NlF8HhCZzzDhXiSxEaWRQ24G3roVBcLk5GWii2xur/oYdCl2zKud Uj6w== X-Gm-Message-State: AODbwcDA4hiAR2jKzWOGP/Qcb8lCDFVXmlddY0+Hne+DIq/OizemBuai MMSnixabhWMy+BrumGWh8bLB0Zr/fg== X-Received: by 10.37.22.9 with SMTP id 9mr25554015ybw.33.1497267206368; Mon, 12 Jun 2017 04:33:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.67 with HTTP; Mon, 12 Jun 2017 04:33:25 -0700 (PDT) In-Reply-To: References: <149583038439.8608.6889631754413770370@ietfa.amsl.com> From: Takahiko Kawasaki Date: Mon, 12 Jun 2017 20:33:25 +0900 Message-ID: To: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="001a1141686af83a380551c1afb5" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 11:33:29 -0000 --001a1141686af83a380551c1afb5 Content-Type: text/plain; charset="UTF-8" Hello, I'm sorry for this FAQ but where can I make comments for the draft of "Mutual TLS Profiles for OAuth Clients"? I found a trivial editorial issue in the last paragraph in "3. Mutual TLS Sender Constrained Resources Access". The second 'that' in "... verify that the that certificate matches ..." should be removed (= that part should be "... verify that the certificate matches ..."). Is it enough to mention it in this mailing list like this? Best Regards, Takahiko Kawasaki 2017-05-27 5:34 GMT+09:00 Brian Campbell : > A new draft of "Mutual TLS Profiles for OAuth Clients" has been published. The changes from the previous version are summarized below. > > > draft-ietf-oauth-mtls-01 > > o Added more explicit details of using RFC 7662 token introspection > with mutual TLS sender constrained access tokens. > o Added an IANA OAuth Token Introspection Response Registration > request for "cnf". > o Specify that tls_client_auth_subject_dn and > tls_client_auth_root_dn are RFC 4514 String Representation of > Distinguished Names. > o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. > o Changed the text in the Section 3 to not be specific about using a > hash of the cert. > o Changed the abbreviated title to 'OAuth Mutual TLS' (previously > was the acronym MTLSPOC). > > > > > ---------- Forwarded message ---------- > From: > Date: Fri, May 26, 2017 at 2:26 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol of the IETF. > > Title : Mutual TLS Profiles for OAuth Clients > Authors : Brian Campbell > John Bradley > Nat Sakimura > Torsten Lodderstedt > Filename : draft-ietf-oauth-mtls-01.txt > Pages : 12 > Date : 2017-05-26 > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for both OAuth > client authentication to the token endpoint as well as for sender > constrained access to OAuth protected resources. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-mtls-01 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-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/ > > _______________________________________________ > 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 > > --001a1141686af83a380551c1afb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm sorry for this FAQ but where can I = make comments for the draft of "Mutual TLS Profiles for OAuth Clients&= quot;?

I found a trivial editorial issue in the last paragraph in &q= uot;3. Mutual TLS Sender Constrained Resources Access". The second = 9;that' in "... verify that the that certificate matches ..."= should be removed (=3D that part should be "... verify that the certi= ficate matches ..."). Is it enough to mention it in this mailing list = like this?

Best Regards,
Takahiko Kawasaki

2017-05-27 5:34 GMT+09:00 Bria= n Campbell <bcampbell@pingidentity.com>:
A n=
ew draft of "Mutual TLS Profiles for OAuth Clients" has been publ=
ished. The changes from the previous version are summarized below. <=
br>

   draft-ietf-oauth-mtls-01

   o  Added more explicit details of using RFC 7662 token introspectio=
n
      with mutual TLS sender constrained access tokens.
   o  Added an IANA OAuth Token Introspection Response Registration
      request for "cnf".
   o  Specify that tls_client_auth_subject_dn and
      tls_client_auth_root_dn are RFC 4514 String Representation of
      Distinguished Names.
   o  Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
   o  Changed the text in the Section 3 to =
not be specific about using a
      hash of the cert.
   o  Changed the abbreviated title to 'OAuth Mutual TLS' (previous=
ly
      was the acronym MTLSPOC).



---------- Forwarded message ----------
From: <internet-drafts@ietf.org><= /span>
Date: Fri, May 26, 2017 at 2:26 PM
Subject: [OAUTH-WG] I-D Act= ion: draft-ietf-oauth-mtls-01.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mutual TLS Profiles for OAuth Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-26

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for bot= h OAuth
=C2=A0 =C2=A0client authentication to the token endpoint as well as for sen= der
=C2=A0 =C2=A0constrained access to OAuth protected resources.


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

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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


--001a1141686af83a380551c1afb5-- From nobody Mon Jun 12 04:57:56 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCAD12EA53 for ; Mon, 12 Jun 2017 04:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdW8d0-zKiP6 for ; Mon, 12 Jun 2017 04:57:52 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 5D25312E957 for ; Mon, 12 Jun 2017 04:57:52 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id l89so50809223pfi.2 for ; Mon, 12 Jun 2017 04:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ptFWx5rZIjoljhAgdT3MiLUIuA2sNtnLDNF7wHpNfRY=; b=aAa7YlpLs4nmPhP4KlE58tLooINqWcASnmcDSYRBeH0H3qk4tr7ZcQvajcQbI0sjJ8 3XhRuijHfNF9xtr9pJlvFsv59dGCZQl+SrGL2p+2qFS9TIKHcbEH9zbMf9oJ0qiXW0nf ijhg3Ic2Ik/BrA5uQRjWsgTTTfzKRw1l9fvO0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ptFWx5rZIjoljhAgdT3MiLUIuA2sNtnLDNF7wHpNfRY=; b=BVxuuXCxdZ+a/QpCrIWROYDIsQftO6RvbGfMY9T3f9OeI1ycugNLMiCaHKaLlDVDvo tfBAhjnaqjr201ZjOaYQQ2QNyBosOC/J/i4KVY+1kQQjchI9NlN5fiSQulpIbz6r8E76 yQf0WXxQ7D8502QBnCeXimYmW65xTWTGMdfE2rH4XEqnJEfSmh9EGBd/LWcra8USme3z +hua+0aFtm+4SZfJA1ndusYaeXjp8bttZ74RfDFzc0wcAjhTsxfyDgq9WPaiKoeDjx5q 56MkOu3DuR36Gu+OfwMC0FuSfY2qZcQiHb8FLVNAm27ro6Fcwt4GvaqzhQ+kr53yupj7 gGlg== X-Gm-Message-State: AODbwcAu5PLl101+Bc0vPSirVRhv4Hce7C4eGmESWZvoGaeIsi2APU7c NFabusAinIXAfp/eCmkk+R5yo+69fTkeh5icl/BRW1tB2fx2p0ZgV6Db1Qrgr18VirY42Zm9vhz Qef43 X-Received: by 10.84.218.71 with SMTP id f7mr54911915plm.180.1497268671922; Mon, 12 Jun 2017 04:57:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Mon, 12 Jun 2017 04:57:21 -0700 (PDT) In-Reply-To: References: <149583038439.8608.6889631754413770370@ietfa.amsl.com> From: Brian Campbell Date: Mon, 12 Jun 2017 05:57:21 -0600 Message-ID: To: Takahiko Kawasaki Cc: oauth Content-Type: multipart/alternative; boundary="f403045d153a52dfb20551c2071a" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 11:57:55 -0000 --f403045d153a52dfb20551c2071a Content-Type: text/plain; charset="UTF-8" Thanks Takahiko, mentioning it on the list is enough. I've fixed it in the editors' draft https://github.com/ietf-oauth-mtls/i-d/commit/c6725e30dd1dc2f77aa293bce7fd1849713ed406 On Mon, Jun 12, 2017 at 5:33 AM, Takahiko Kawasaki wrote: > Hello, > > I'm sorry for this FAQ but where can I make comments for the draft of > "Mutual TLS Profiles for OAuth Clients"? > > I found a trivial editorial issue in the last paragraph in "3. Mutual TLS > Sender Constrained Resources Access". The second 'that' in "... verify that > the that certificate matches ..." should be removed (= that part should be > "... verify that the certificate matches ..."). Is it enough to mention it > in this mailing list like this? > > Best Regards, > Takahiko Kawasaki > > 2017-05-27 5:34 GMT+09:00 Brian Campbell : > >> A new draft of "Mutual TLS Profiles for OAuth Clients" has been published. The changes from the previous version are summarized below. >> >> >> draft-ietf-oauth-mtls-01 >> >> o Added more explicit details of using RFC 7662 token introspection >> with mutual TLS sender constrained access tokens. >> o Added an IANA OAuth Token Introspection Response Registration >> request for "cnf". >> o Specify that tls_client_auth_subject_dn and >> tls_client_auth_root_dn are RFC 4514 String Representation of >> Distinguished Names. >> o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. >> o Changed the text in the Section 3 to not be specific about using a >> hash of the cert. >> o Changed the abbreviated title to 'OAuth Mutual TLS' (previously >> was the acronym MTLSPOC). >> >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Fri, May 26, 2017 at 2:26 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol of the IETF. >> >> Title : Mutual TLS Profiles for OAuth Clients >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-01.txt >> Pages : 12 >> Date : 2017-05-26 >> >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for both OAuth >> client authentication to the token endpoint as well as for sender >> constrained access to OAuth protected resources. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-01 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-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/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f403045d153a52dfb20551c2071a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ta= kahiko, mentioning it on the list is enough. I've fixed it in th= e editors' draft https://github.com/ietf-oauth-= mtls/i-d/commit/c6725e30dd1dc2f77aa293bce7fd1849713ed406

On Mon, Jun 12, 2017 a= t 5:33 AM, Takahiko Kawasaki <daru.tk@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hello,

I'm sorry= for this FAQ but where can I make comments for the draft of "Mutual T= LS Profiles for OAuth Clients"?

I found a trivial editorial iss= ue in the last paragraph in "3. Mutual TLS Sender Constrained Resource= s Access". The second 'that' in "... verify that the that= certificate matches ..." should be removed (=3D that part should be &= quot;... verify that the certificate matches ..."). Is it enough to me= ntion it in this mailing list like this?

Best Regards,
Takahiko K= awasaki

2017-05-27 5:34 GMT+09:00 Brian Cam= pbell <bcampbell@pingidentity.com>:
A new draft of "Mutual TLS Profiles for OAuth Clients&quo=
t; has been published. The changes from the previous version are summarized=
 below. 

   draft-ietf-oauth-mtls-01

   o  Added more explicit details of using RFC 7662 token introspectio=
n
      with mutual TLS sender constrained access tokens.
   o  Added an IANA OAuth Token Introspection Response Registration
      request for "cnf".
   o  Specify that tls_client_auth_subject_dn and
      tls_client_auth_root_dn are RFC 4514 String Representation of
      Distinguished Names.
   o  Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
   o  Changed the text in the Section 3 to =
not be specific about using a
      hash of the cert.
   o  Changed the abbreviated title to 'OAuth Mutual TLS' (previous=
ly
      was the acronym MTLSPOC).



---------- Forwarded message -= ---------
From: <= ;internet-dra= fts@ietf.org>
Date: Fri, May 26, 2017 at 2:26 PM
Subjec= t: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt
To: i-d-announce@ietf.org
= Cc: oauth@ietf.org<= br>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mutual TLS Profiles for OAuth Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-26

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for bot= h OAuth
=C2=A0 =C2=A0client authentication to the token endpoint as well as for sen= der
=C2=A0 =C2=A0constrained access to OAuth protected resources.


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

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045d153a52dfb20551c2071a-- From nobody Mon Jun 12 06:23:27 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E447A127869 for ; Mon, 12 Jun 2017 06:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcW1TaRcYAJR for ; Mon, 12 Jun 2017 06:23:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75841273B1 for ; Mon, 12 Jun 2017 06:23:23 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3969D5CB; Mon, 12 Jun 2017 13:23:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3969D5CB Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bburke@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3969D5CB Received: from ovpn-116-70.phx2.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id C8AFB777CE; Mon, 12 Jun 2017 13:23:22 +0000 (UTC) To: Aaron Parecki Cc: OAuth WG References: From: Bill Burke Message-ID: Date: Mon, 12 Jun 2017 09:23:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3668E045D4B55C5573D24C4C" Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 12 Jun 2017 13:23:23 +0000 (UTC) Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:23:26 -0000 This is a multi-part message in MIME format. --------------3668E045D4B55C5573D24C4C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I've read about these techniques, but, its just not a good user experience. I'm thinking more of something where the command line console is the sole user agent and the auth server drives a plain text based interaction much like an HTTP Server drives interaction with HTML and the browser. This isn't anything complex. It should be a simple protocol, but I'd like to piggy back on existing solutions to build some consensus around what I think is a common issue with using OAuth. If there isn't anything going on here in the OAuth group surrounding this, would be willing to draw up a Draft if there is interest. On 6/11/17 11:58 PM, Aaron Parecki wrote: > I've seen this done a few ways: > > * The Device Flow: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what > you see on browserless devices like the Apple TV logging in to a cable > provider from your phone. A short code is generated and displayed on > the screen, you launch a browser on your phone and enter the code. > This would work just as well from the command line on the same device. > * I've also seen apps use the authorization flow, by displaying the > authorization URL on the command line prompt and instructing the user > to open it in a browser. The redirect URI is a hosted web page that > displays the authorization code and instructs the user to paste it > back at the terminal. > * The command line app can launch an HTTP server on localhost and use > that as the redirect URL for the authorization code flow. This option > ends up being the most seamless since it works like a traditional flow > without any special instructions to the user. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke > wrote: > > Has anybody done any spec work around doing oauth from command > line interfaces? We're looking for something where the auth > server can generate text-based challenges that are rendered in the > console window that query for simple text input over possibly > multiple requests. I'm not talking about Resource Owner or Client > Credentials grant. The command line client may not know the > credential types required for a successful token request. It would > be easy to write a simple protocol, but I'd rather just do > something around any existing internet draft or rfc that somebody > has put some thought into. Hope I'm making sense here. > > Thanks, > > Bill Burke > > Red Hat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --------------3668E045D4B55C5573D24C4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I've read about these techniques, but, its just not a good user experience.  I'm thinking more of something where the command line console is the sole user agent and the auth server drives a plain text based interaction much like an HTTP Server drives interaction with HTML and the browser. 

This isn't anything complex.  It should be a simple protocol, but I'd like to piggy back on existing solutions to build some consensus around what I think is a common issue with using OAuth.  If there isn't anything going on here in the OAuth group surrounding this, would be willing to draw up a Draft if there is interest.


On 6/11/17 11:58 PM, Aaron Parecki wrote:
I've seen this done a few ways:

* The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal.
* The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.

----
Aaron Parecki


On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <bburke@redhat.com> wrote:
Has anybody done any spec work around doing oauth from command line interfaces?  We're looking for something where the auth server can generate text-based challenges that are rendered in the console window that query for simple text input over possibly multiple requests.  I'm not talking about Resource Owner or Client Credentials grant.  The command line client may not know the credential types required for a successful token request. It would be easy to write a simple protocol, but I'd rather just do something around any existing internet draft or rfc that somebody has put some thought into.  Hope I'm making sense here.

Thanks,

Bill Burke

Red Hat

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


--------------3668E045D4B55C5573D24C4C-- From nobody Mon Jun 12 06:29:55 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024E912EACC for ; Mon, 12 Jun 2017 06:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4drD4sHbb4u for ; Mon, 12 Jun 2017 06:29:51 -0700 (PDT) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDB912EAB0 for ; Mon, 12 Jun 2017 06:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6892; q=dns/txt; s=VRSN; t=1497274190; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=n9IvA7rW1s0ClOPmsmeJ98xVLwTo7JqWanuRtlFJ4cY=; b=ad0wvDTJU7GwVxd62B3KnPH3aJ7Tr9OmTf4p2UVacfZ1y2915bZybGJF 95W4EULZwdhEWCK+wHe+8D32bT+rz8+FKLWqK0vID8ITzVikj0nG0le2p yMRDUz6OjSJSajSJRzLgaFQdHey5XKaPsPJOAbMko3SsivV01FYk9UVyq mGvAGT9iud62jyQTirod9g9jG/C3FEYlrH1cDsOHT0ZwLfS/tzKgU/77F qw8wdpOWvQjJbAoIaeXjPOA0Euv99zXtEWkMJhjPyXqnbMuqKEPZJl16V YPUjFJ0jIzyxEfj+y8zlbKQg20fB688DqIVrjielL2AlDknEGw/SASsqe A==; X-IronPort-AV: E=Sophos;i="5.39,333,1493683200"; d="scan'208,217";a="3666427" IronPort-PHdr: =?us-ascii?q?9a23=3AtKVvzxDv7pC8vSgUe9q0UyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPX+osbcNUDSrc9gkEXOFd2CrakV1KyO6+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhjexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfO?= =?us-ascii?q?pWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnM?= =?us-ascii?q?VhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Xymp4aV2Rx/ykC?= =?us-ascii?q?oJNyA3/nzLisJ+j6xbrhCupx1jzIHbe4yaLuZyc6fHcN8GWWZMXMBcXDFBDIOm?= =?us-ascii?q?aIsPCvIMMehaoYn6o1sOqQWxBQ+3C+zx1jBIhWf61rAn3es9FgHGwBAgE9wTu3?= =?us-ascii?q?nTt9X1NKASUeSxzKbWyzXMdO1Z1iv+6IXTbBAuv+uMXbNrccrQxkkvERnJgUmX?= =?us-ascii?q?qYzgJj6Y0PkGvWuD7+d4SO6jl3QrpxxzrzWh3Msgl4nEi4wPxlza+ih0wJ45Kc?= =?us-ascii?q?CkREJhfNKpEodcuzuHO4Z5Qc4uWXxktSU8x7Ybo5C0ZjIKx44ixxPHbvyHdJWH?= =?us-ascii?q?7Qz7WeaKJDd4mGpleLWihxau6USgyvPzVs2z0FtStSVFiN/Mum0J1x3c78iIUP?= =?us-ascii?q?p9/kOm2TaSywDf9v9ILVoqlaXFMZ4hw6UwlpscsUTFBCP5hEL2jKqOekUl/Oin?= =?us-ascii?q?9fjnb637qpOALYN4lwPzP6o0lsCiAek1PBICU3aU9Om8zLHj+Ff2QLROjv04iK?= =?us-ascii?q?nZt5XaKNwApq65BA9V1oIj5Ai5Dzi9ztsXgXoHIUlbeB2ZlYjpOkrOIPH3Dfe5?= =?us-ascii?q?mVijjDBrx/XeMr37HprNNmTDkKvmfbtl7E5T0hczzcxf559PC7EOPu7zWkHruN?= =?us-ascii?q?zfFB85PBS+w/z7B9VlyoMeRWWPD7eDP6zIq1+I4eQvLvKUZIAPojbyNeQq5/3v?= =?us-ascii?q?jXMjhVAdeqyp14MNaH+kBvRmP1mZYX30j9gaCmgKoxA+TO/0h1CZSz5ceWu9X6?= =?us-ascii?q?Im6TEnEo6pEYDDRoX+yICGiW30FJdLfGNLIkqBHXfha8OPXPJDImrGKMV8iD8J?= =?us-ascii?q?faKsR48oyVelswqsj/ItYePd4CoenYrqztV+5OyVnhY3unY8W82UyWaLZ3l9hG?= =?us-ascii?q?4DRD5w16d69x9T0FCGhOJYhPhcGNpZ6vhKFk8BPpnA06YyX8vyXQbFc9GDRV2l?= =?us-ascii?q?asurGzAqT903hdQJZhAuSJ2Zkhnf0n/yUPcunLuRCcls/w=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2F0EwC9lj5Z//WZrQpcHAEBBAEBCgEBFgEBAQMBAQEJAQE?= =?us-ascii?q?BgkQ8gQ+BDQeDbZwGgyKSYRCCAYYkAhqDFBcBAQEBAQEBAQEBAQKBEIIzIoJDA?= =?us-ascii?q?QEBAQMjCkwQAgEIDQQEAQELHQMCAgIwFAkIAgQBDQUIE4ktsGaCJiuLOQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAR2EUIISgV+CT1GEOhoYNIJcMIIxBZ45BgKVTYkxh?= =?us-ascii?q?k+UbCEBgUB0URJsAYFBhFp2iFGBDQEBAQ?= Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v5CDTnPN020415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jun 2017 09:29:49 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Mon, 12 Jun 2017 09:29:48 -0400 From: "Hollenbeck, Scott" To: "'bburke@redhat.com'" , "'aaron@parecki.com'" CC: "'oauth@ietf.org'" Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] oauth with command line clients Thread-Index: AQHS438YoDfvDoWY6k+/BPWBt667faIhN/Sw Date: Mon, 12 Jun 2017 13:29:48 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F73E441C6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F73E441C6BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:29:53 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F73E441C6BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QmlsbCBCdXJrZQ0KU2VudDogTW9uZGF5LCBKdW5lIDEyLCAyMDE3IDk6MjMgQU0NClRvOiBBYXJv biBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbT4NCkNjOiBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbT0FVVEgtV0ddIG9hdXRoIHdpdGggY29tbWFu ZCBsaW5lIGNsaWVudHMNCg0KDQoNCkkndmUgcmVhZCBhYm91dCB0aGVzZSB0ZWNobmlxdWVzLCBi dXQsIGl0cyBqdXN0IG5vdCBhIGdvb2QgdXNlciBleHBlcmllbmNlLiAgSSdtIHRoaW5raW5nIG1v cmUgb2Ygc29tZXRoaW5nIHdoZXJlIHRoZSBjb21tYW5kIGxpbmUgY29uc29sZSBpcyB0aGUgc29s ZSB1c2VyIGFnZW50IGFuZCB0aGUgYXV0aCBzZXJ2ZXIgZHJpdmVzIGEgcGxhaW4gdGV4dCBiYXNl ZCBpbnRlcmFjdGlvbiBtdWNoIGxpa2UgYW4gSFRUUCBTZXJ2ZXIgZHJpdmVzIGludGVyYWN0aW9u IHdpdGggSFRNTCBhbmQgdGhlIGJyb3dzZXIuDQoNClRoaXMgaXNuJ3QgYW55dGhpbmcgY29tcGxl eC4gIEl0IHNob3VsZCBiZSBhIHNpbXBsZSBwcm90b2NvbCwgYnV0IEknZCBsaWtlIHRvIHBpZ2d5 IGJhY2sgb24gZXhpc3Rpbmcgc29sdXRpb25zIHRvIGJ1aWxkIHNvbWUgY29uc2Vuc3VzIGFyb3Vu ZCB3aGF0IEkgdGhpbmsgaXMgYSBjb21tb24gaXNzdWUgd2l0aCB1c2luZyBPQXV0aC4gIElmIHRo ZXJlIGlzbid0IGFueXRoaW5nIGdvaW5nIG9uIGhlcmUgaW4gdGhlIE9BdXRoIGdyb3VwIHN1cnJv dW5kaW5nIHRoaXMsIHdvdWxkIGJlIHdpbGxpbmcgdG8gZHJhdyB1cCBhIERyYWZ0IGlmIHRoZXJl IGlzIGludGVyZXN0Lg0KDQpbU0FIXSBJ4oCZbSBjZXJ0YWlubHkgaW50ZXJlc3RlZCEgSSBoYXZl IGEgdXNlIGNhc2UgZm9yIGZlZGVyYXRlZCBjbGllbnQgYXV0aGVudGljYXRpb24gYW5kIGF1dGhv cml6YXRpb24gZm9yIHRoZSBSZWdpc3RyYXRpb24gRGF0YSBBY2Nlc3MgUHJvdG9jb2wgKFJEQVAp IHRoYXQgaGFzIHRoZSBzYW1lIG5lZWQgZm9yIGNvbW1hbmQgbGluZSB3ZWIgc2VydmljZSBjbGll bnRzIGxpa2Ugd2dldCBhbmQgY3VybC4NCg0KDQoNClNjb3R0DQoNCg== --_000_831693C2CDA2E849A7D7A712B24E257F73E441C6BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5CaWxsIEJ1cmtlPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSAxMiwgMjAx NyA5OjIzIEFNPGJyPg0KPGI+VG86PC9iPiBBYXJvbiBQYXJlY2tpICZsdDthYXJvbkBwYXJlY2tp LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBSZTogW09BVVRILVdHXSBvYXV0aCB3aXRo IGNvbW1hbmQgbGluZSBjbGllbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5JJ3ZlIHJlYWQgYWJvdXQgdGhlc2Ug dGVjaG5pcXVlcywgYnV0LCBpdHMganVzdCBub3QgYSBnb29kIHVzZXIgZXhwZXJpZW5jZS4mbmJz cDsgSSdtIHRoaW5raW5nIG1vcmUgb2Ygc29tZXRoaW5nIHdoZXJlIHRoZSBjb21tYW5kIGxpbmUg Y29uc29sZSBpcyB0aGUgc29sZSB1c2VyIGFnZW50IGFuZCB0aGUgYXV0aCBzZXJ2ZXIgZHJpdmVz IGEgcGxhaW4gdGV4dCBiYXNlZCBpbnRlcmFjdGlvbiBtdWNoIGxpa2UgYW4gSFRUUCBTZXJ2ZXIg ZHJpdmVzIGludGVyYWN0aW9uDQogd2l0aCBIVE1MIGFuZCB0aGUgYnJvd3Nlci4mbmJzcDsgPG86 cD48L286cD48L3A+DQo8cD5UaGlzIGlzbid0IGFueXRoaW5nIGNvbXBsZXguJm5ic3A7IEl0IHNo b3VsZCBiZSBhIHNpbXBsZSBwcm90b2NvbCwgYnV0IEknZCBsaWtlIHRvIHBpZ2d5IGJhY2sgb24g ZXhpc3Rpbmcgc29sdXRpb25zIHRvIGJ1aWxkIHNvbWUgY29uc2Vuc3VzIGFyb3VuZCB3aGF0IEkg dGhpbmsgaXMgYSBjb21tb24gaXNzdWUgd2l0aCB1c2luZyBPQXV0aC4mbmJzcDsgSWYgdGhlcmUg aXNuJ3QgYW55dGhpbmcgZ29pbmcgb24gaGVyZSBpbiB0aGUgT0F1dGggZ3JvdXAgc3Vycm91bmRp bmcNCiB0aGlzLCB3b3VsZCBiZSB3aWxsaW5nIHRvIGRyYXcgdXAgYSBEcmFmdCBpZiB0aGVyZSBp cyBpbnRlcmVzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bU0FIXSA8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SeKAmW0gY2VydGFpbmx5IGludGVyZXN0ZWQhIEkgaGF2ZSBhIHVz ZSBjYXNlIGZvciBmZWRlcmF0ZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0 aW9uIGZvciB0aGUgUmVnaXN0cmF0aW9uIERhdGEgQWNjZXNzIFByb3RvY29sIChSREFQKSB0aGF0 IGhhcw0KIHRoZSBzYW1lIG5lZWQgZm9yIGNvbW1hbmQgbGluZSB3ZWIgc2VydmljZSBjbGllbnRz IGxpa2Ugd2dldCBhbmQgY3VybC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlNjb3R0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_831693C2CDA2E849A7D7A712B24E257F73E441C6BRN1WNEXMBX01vc_-- From nobody Mon Jun 12 09:20:51 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8669129417 for ; Mon, 12 Jun 2017 09:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT-4G2Gf82ET for ; Mon, 12 Jun 2017 09:20:38 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 39C4E129408 for ; Mon, 12 Jun 2017 09:20:38 -0700 (PDT) Received: from [IPv6:2601:282:281:3a11:2d1b:594c:1f79:966b] (unknown [IPv6:2601:282:281:3a11:2d1b:594c:1f79:966b]) by alkaline-solutions.com (Postfix) with ESMTPSA id 3A262315F3; Mon, 12 Jun 2017 16:20:37 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C206F3BB-F513-43CC-84F3-7BE19927AA21" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 12 Jun 2017 10:20:36 -0600 In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F73E441C6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Cc: "bburke@redhat.com" , "aaron@parecki.com" , "oauth@ietf.org" To: "Hollenbeck, Scott" References: <831693C2CDA2E849A7D7A712B24E257F73E441C6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 16:20:48 -0000 --Apple-Mail=_C206F3BB-F513-43CC-84F3-7BE19927AA21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI, A few years ago I did a demonstration on OpenID Connect at Cloud = Identity Summit using a collection of bash scripts and command-line = utilities (nc, jq). I used the macOS system command =E2=80=98open=E2=80=99= to launch a browser, and netcat to field the response as a poor man=E2=80= =99s HTTP endpoint. The code for that presentation is at = https://github.com/dwaite/Presentation-Code-OpenID-Connect-Dynamic-Client-= Registration A few options for the user challenge/consent portion of the = authentication are: - pop up the system browser (you can use window.close() to dismiss on = redirect back to your client) - thats the one I used. - device flow - use a console browser like lynx or ELinks (which has rudimentary = ecmascript support at a fairly big cost) - use non-HTML request/response API (around some custom MIME type) to = drive a user agent through the authentication/scope approval/etc stages = of your AS - punt and use resource owner credentials grant. -DW =20 > On Jun 12, 2017, at 7:29 AM, Hollenbeck, Scott = wrote: >=20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Bill Burke > Sent: Monday, June 12, 2017 9:23 AM > To: Aaron Parecki > > Cc: OAuth WG > > Subject: [EXTERNAL] Re: [OAUTH-WG] oauth with command line clients > =20 > I've read about these techniques, but, its just not a good user = experience. I'm thinking more of something where the command line = console is the sole user agent and the auth server drives a plain text = based interaction much like an HTTP Server drives interaction with HTML = and the browser. =20 >=20 > This isn't anything complex. It should be a simple protocol, but I'd = like to piggy back on existing solutions to build some consensus around = what I think is a common issue with using OAuth. If there isn't = anything going on here in the OAuth group surrounding this, would be = willing to draw up a Draft if there is interest. >=20 > [SAH] I=E2=80=99m certainly interested! I have a use case for = federated client authentication and authorization for the Registration = Data Access Protocol (RDAP) that has the same need for command line web = service clients like wget and curl. > =20 > Scott > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_C206F3BB-F513-43CC-84F3-7BE19927AA21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI, A few years ago I did a demonstration on OpenID Connect = at Cloud Identity Summit using a collection of bash scripts and = command-line utilities (nc, jq). I used the macOS system command = =E2=80=98open=E2=80=99 to launch a browser, and netcat to field the = response as a poor man=E2=80=99s HTTP endpoint.  The code for that = presentation is at https://github.com/dwaite/Presentation-Code-OpenID-Connect-Dyna= mic-Client-Registration

A few options for the user = challenge/consent portion of the authentication are:
- pop up the system browser (you can use window.close() to = dismiss on redirect back to your client) - thats the one I = used.
- device flow
- use a = console browser like lynx or ELinks (which has rudimentary ecmascript = support at a fairly big cost)
- use non-HTML = request/response API (around some custom MIME type) to drive a user = agent through the authentication/scope approval/etc stages of your = AS
- punt and use resource owner credentials = grant.

-DW
 
On = Jun 12, 2017, at 7:29 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Bill Burke
Sent: Monday, June 12, 2017 9:23 = AM
To: Aaron Parecki <aaron@parecki.com>
Cc: OAuth WG <oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] = oauth with command line clients
 

I've read about these techniques, but, its just not a good = user experience.  I'm thinking more of something where the command = line console is the sole user agent and the auth server drives a plain = text based interaction much like an HTTP Server drives interaction with = HTML and the browser.  

This isn't anything complex.  It should be a simple = protocol, but I'd like to piggy back on existing solutions to build some = consensus around what I think is a common issue with using OAuth.  = If there isn't anything going on here in the OAuth group surrounding = this, would be willing to draw up a Draft if there is interest.

[SAH] I=E2=80=99m certainly = interested! I have a use case for federated client authentication and = authorization for the Registration Data Access Protocol (RDAP) that has = the same need for command line web service clients like wget and = curl.
 
Scott
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_C206F3BB-F513-43CC-84F3-7BE19927AA21-- From nobody Mon Jun 12 11:19:50 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617ED12EB59 for ; Mon, 12 Jun 2017 11:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8kcwiISQXK2 for ; Mon, 12 Jun 2017 11:19:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 A759D12EB5D for ; Mon, 12 Jun 2017 11:19:43 -0700 (PDT) Received: from [192.168.91.196] ([80.92.114.129]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MVNWU-1dKyRV0oiE-00Yh9A; Mon, 12 Jun 2017 20:19:35 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Cc: Hannes Tschofenig , Kepeng Li Message-ID: Date: Mon, 12 Jun 2017 20:19:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:FqSW3HZNphTSWConvw4D227/mrnnYye0ibr2tUTwTcPRydE1rnE 1HjS5/KB2or11dR+ybyhOtNmhy4vuzgEeNYoUIwczi33QCMteCHDkNk2DYEykrEu08oOIAS tNLmQo1OpFnVR9aD4kJAQu7nMEXAd03jxXEHcm0TsUUU5C083fxVjUqcbC/rlN8smhnMcCR xaUobNDH+24Yf012xRPkA== X-UI-Out-Filterresults: notjunk:1;V01:K0:hZtWrMYdLks=:rndcX6s+1wF8ofxSqbFhvD L6U20qFVUV7yxgsglUJqkcParLncjieQjSSE1hkU5LHbjoNavwvSqpgOM77tqe6CkufQ9z9pS i6U36LQvntSF5O1j/8YlFRTqhP9BXqlx1Q94PFKmpLunFOmPPMX0JBUHDuZzmSCwlU+12I8vX 9SVwVlhMCk1hrZy+fRmRkeTVP0GezgzZ3GGcdaoJAR+OOvv1si3cUUbrwwlZBlULSlUrt7t+H KPm/qrdEMkPtjDdXP0U22uoOsf0tLFo8TSyxkh4Ldx0DXK1YD2PXQVVDQq2SxwMaRMM+xlxY3 888YEtd4gfQ+rawjNaymXsk3z+aUHBhM7iT6oaVWRsdJNot8F9ao7f5qnUy95qrpITSdc/zKM 5/x9b4+y63EH6bmuTgx7VIT2mEAZ1aY1P9gSGKWkgc+9gq6m8aE+mm/ASUfSHnAnHRiRbCqQh wDAeeOSZO5Q9KEw7fjFVb1ldqVGR0SIqlLJRLlos0MM5Ji53J8XGvF0DlLoOFUPGlrRtgBDS9 1lbrQMewJNkn0B01xf+8+UNQFX+Lv4Dq4FbK+yBdzcRYS4WTbkiuIFZR3BohYezHvcSrrb7Ts tXYk9hfXt3gLaof/5RlF6aq8zoS6nS/jr1D+X5mJZ3ZnvlEt6np35n3s0fEM+5v91g/FxHmib pPQoDQL45dPVT944tVAyD+mbYLuchXFEMzSRWdXJ2YxI9pW9a6dW6usvz+N6qrD9I9WOm7dqU LhJSnbozSOEs8ZsRPaqk4ZI1MaU08o57thWoRoKb4mv9Ma1Oe139w5CzG9W6IVNAMjnTDN9G/ Mh5b/2n Archived-At: Subject: [OAUTH-WG] Potential uses of PoP keys in CBOR Web Tokens (CWTs) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:19:48 -0000 Hi all, RFC 7800 defines how to communicate Proof of Possession (PoP) keys for JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of the JSON/JOSE JWT spec. The ACE working group is planning to also define a CBOR/COSE equivalent of RFC 7800 and is interested in knowing how you might use CBOR proof-of-possession keys for CWTs. Please drop us a message if you are using CBOR PoP keys for CWTs. We would like to learn more about your usage. Ciao Hannes & Kepeng From nobody Mon Jun 12 11:22:34 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CB112EB63 for ; Mon, 12 Jun 2017 11:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUjcPOsia92I for ; Mon, 12 Jun 2017 11:22:30 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.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 9AA4B12EB66 for ; Mon, 12 Jun 2017 11:22:28 -0700 (PDT) X-AuditID: 12074425-78fff700000009de-6a-593edbe3a476 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id FC.13.02526.3EBDE395; Mon, 12 Jun 2017 14:22:27 -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 v5CIMQuG008256; Mon, 12 Jun 2017 14:22:26 -0400 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 v5CIMNi1012190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Jun 2017 14:22:24 -0400 To: Aaron Parecki , Bill Burke Cc: OAuth WG References: From: Justin Richer Message-ID: <83057e12-1d09-1b2c-88a4-b1918c9a0b5b@mit.edu> Date: Mon, 12 Jun 2017 14:22:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F0A4CE172F5B267BAA005BBD" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixCmqrPv4tl2kwcNnChbnVrlZ9G7dyWhx 8u0rNgdmjyVLfjJ5NMxM83i/7ypbAHMUl01Kak5mWWqRvl0CV8bfk6uZC1Z4VXRtfMjawHjG vIuRk0NCwERixvW5TF2MXBxCAouZJN7+3MYO4WxklLgyv58VwrnNJNG7/iY7SIuwgLlEx65f QAkODhEBV4lrnZ4gYWYBWYnWk5egmlsYJRbv+MEKkmATUJWYvqaFCcTmFbCS2Hp9PwuIzQIU 37f+CCOILSoQI/Fow1moGkGJkzOfsIDM5xQIlHh70BZifpjEpXffGCFscYlbT+YzTWAUmIWk YxaSsllIyiBsM4l5mx8yQ9jyEtvfzgGyOYBsNYllrUow4eats5kXMLKvYpRNya3SzU3MzClO TdYtTk7My0st0rXQy80s0UtNKd3ECIoLdhfVHYxz/nodYhTgYFTi4WWYahcpxJpYVlyZe4hR koNJSZR3yxWbSCG+pPyUyozE4oz4otKc1OJDjBIczEoivOzAaBTiTUmsrEotyodJSXOwKInz ims0RggJpCeWpGanphakFsFkZTg4lCR4T9wCahQsSk1PrUjLzClBSDNxcIIM5wEaLnUdZHhx QWJucWY6RP4Uo6KUOO97kGYBkERGaR5cLyhtJbw9bPqKURzoFWFeDZAqHmDKg+t+BTSYCWjw dZCPeItLEhFSUg2M5pVmBzZf1N3TF13xq2W/1wKLp5yPTi3i63+byqO2Osx+v05rzfkF8pOr 67KPFE1Md7vet2TlhAmvOU/N2z/p+UyeZ2fd97yQOWFkn+ggeEik59CO96JXd2hpTTa23Ln+ q+HeDVXfjdYempJ47ecphgnR4iWnOn1v/+ZJmLwgVs9683bff3/cbimxFGckGmoxFxUnAgBZ SW+sNgMAAA== Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:22:33 -0000 This is a multi-part message in MIME format. --------------F0A4CE172F5B267BAA005BBD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I second the recommendation to use the device flow for this kind of system. The commandline client would print out a text string for the user to enter into their browser elsewhere. If you can pop up a system browser then it's even easier and you can just use the auth code flow, but it's a lot to assume that a commandline app can have that kind of capability available to it. Printing out a string? That's easy and universal. That's why I say go with the device flow. The thing is, at the end of the day, you need the user to authenticate to the AS if you're going to get delegated access from them. That's really the whole point of the OAuth protocol, after all. So you can either do that in a local browser of some kind (like popping a system browser), on another device (with the device flow), or you can be evil and use the username/password grant and just steal the user's credentials yourself. If it's not clear, I don't recommend that, basically ever. -- Justin On 6/11/2017 11:58 PM, Aaron Parecki wrote: > I've seen this done a few ways: > > * The Device Flow: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what > you see on browserless devices like the Apple TV logging in to a cable > provider from your phone. A short code is generated and displayed on > the screen, you launch a browser on your phone and enter the code. > This would work just as well from the command line on the same device. > * I've also seen apps use the authorization flow, by displaying the > authorization URL on the command line prompt and instructing the user > to open it in a browser. The redirect URI is a hosted web page that > displays the authorization code and instructs the user to paste it > back at the terminal. > * The command line app can launch an HTTP server on localhost and use > that as the redirect URL for the authorization code flow. This option > ends up being the most seamless since it works like a traditional flow > without any special instructions to the user. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke > wrote: > > Has anybody done any spec work around doing oauth from command > line interfaces? We're looking for something where the auth > server can generate text-based challenges that are rendered in the > console window that query for simple text input over possibly > multiple requests. I'm not talking about Resource Owner or Client > Credentials grant. The command line client may not know the > credential types required for a successful token request. It would > be easy to write a simple protocol, but I'd rather just do > something around any existing internet draft or rfc that somebody > has put some thought into. Hope I'm making sense here. > > Thanks, > > Bill Burke > > Red Hat > > _______________________________________________ > 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 --------------F0A4CE172F5B267BAA005BBD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I second the recommendation to use the device flow for this kind of system. The commandline client would print out a text string for the user to enter into their browser elsewhere.

If you can pop up a system browser then it's even easier and you can just use the auth code flow, but it's a lot to assume that a commandline app can have that kind of capability available to it. Printing out a string? That's easy and universal. That's why I say go with the device flow.

The thing is, at the end of the day, you need the user to authenticate to the AS if you're going to get delegated access from them. That's really the whole point of the OAuth protocol, after all. So you can either do that in a local browser of some kind (like popping a system browser), on another device (with the device flow), or you can be evil and use the username/password grant and just steal the user's credentials yourself. If it's not clear, I don't recommend that, basically ever.

 -- Justin


On 6/11/2017 11:58 PM, Aaron Parecki wrote:
I've seen this done a few ways:

* The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal.
* The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.

----
Aaron Parecki


On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <bburke@redhat.com> wrote:
Has anybody done any spec work around doing oauth from command line interfaces?  We're looking for something where the auth server can generate text-based challenges that are rendered in the console window that query for simple text input over possibly multiple requests.  I'm not talking about Resource Owner or Client Credentials grant.  The command line client may not know the credential types required for a successful token request. It would be easy to write a simple protocol, but I'd rather just do something around any existing internet draft or rfc that somebody has put some thought into.  Hope I'm making sense here.

Thanks,

Bill Burke

Red Hat

_______________________________________________
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

--------------F0A4CE172F5B267BAA005BBD-- From nobody Mon Jun 12 11:34:28 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E83712EAF1 for ; Mon, 12 Jun 2017 11:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ8RePsTh53C for ; Mon, 12 Jun 2017 11:34:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 4EB0012960D for ; Mon, 12 Jun 2017 11:34:23 -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 v5CIYLHj010878 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Jun 2017 18:34:21 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v5CIYKqG025790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Jun 2017 18:34:20 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5CIYIFV029703; Mon, 12 Jun 2017 18:34:19 GMT Received: from [10.0.1.7] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jun 2017 11:34:18 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_51CFB8D3-007B-4FFF-B89A-AAB80FEB2A5C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 12 Jun 2017 11:34:16 -0700 In-Reply-To: <83057e12-1d09-1b2c-88a4-b1918c9a0b5b@mit.edu> Cc: Aaron Parecki , Bill Burke , OAuth WG To: Justin Richer References: <83057e12-1d09-1b2c-88a4-b1918c9a0b5b@mit.edu> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:34:26 -0000 --Apple-Mail=_51CFB8D3-007B-4FFF-B89A-AAB80FEB2A5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1=20 The point of OAuth is to break away from using UID/Password (basic = auth). =20 The device flow is the best way to allow stronger authentication of the = authorizing user while still allowing a limited input device (e.g. = command line) to work. =20 Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 12, 2017, at 11:22 AM, Justin Richer wrote: >=20 > I second the recommendation to use the device flow for this kind of = system. The commandline client would print out a text string for the = user to enter into their browser elsewhere.=20 > If you can pop up a system browser then it's even easier and you can = just use the auth code flow, but it's a lot to assume that a commandline = app can have that kind of capability available to it. Printing out a = string? That's easy and universal. That's why I say go with the device = flow. >=20 > The thing is, at the end of the day, you need the user to authenticate = to the AS if you're going to get delegated access from them. That's = really the whole point of the OAuth protocol, after all. So you can = either do that in a local browser of some kind (like popping a system = browser), on another device (with the device flow), or you can be evil = and use the username/password grant and just steal the user's = credentials yourself. If it's not clear, I don't recommend that, = basically ever.=20 > -- Justin >=20 > On 6/11/2017 11:58 PM, Aaron Parecki wrote: >> I've seen this done a few ways: >>=20 >> * The Device Flow: = https://tools.ietf.org/html/draft-ietf-oauth-device-flow = which is what you see on browserless devices = like the Apple TV logging in to a cable provider from your phone. A = short code is generated and displayed on the screen, you launch a = browser on your phone and enter the code. This would work just as well = from the command line on the same device. >> * I've also seen apps use the authorization flow, by displaying the = authorization URL on the command line prompt and instructing the user to = open it in a browser. The redirect URI is a hosted web page that = displays the authorization code and instructs the user to paste it back = at the terminal. >> * The command line app can launch an HTTP server on localhost and use = that as the redirect URL for the authorization code flow. This option = ends up being the most seamless since it works like a traditional flow = without any special instructions to the user. >>=20 >> ---- >> Aaron Parecki >> aaronparecki.com = >> @aaronpk = >>=20 >>=20 >> On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke > wrote: >> Has anybody done any spec work around doing oauth from command line = interfaces? We're looking for something where the auth server can = generate text-based challenges that are rendered in the console window = that query for simple text input over possibly multiple requests. I'm = not talking about Resource Owner or Client Credentials grant. The = command line client may not know the credential types required for a = successful token request. It would be easy to write a simple protocol, = but I'd rather just do something around any existing internet draft or = rfc that somebody has put some thought into. Hope I'm making sense = here. >>=20 >> Thanks, >>=20 >> Bill Burke >>=20 >> Red Hat >>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1= 0&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Dj2jP9OSVjttUWWQMazHX= MhLBvLqfXsFJB6GEOh_Mv9k&s=3DeodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=3D= =20 --Apple-Mail=_51CFB8D3-007B-4FFF-B89A-AAB80FEB2A5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 

The point of OAuth is to break away from using UID/Password = (basic auth).   

The device flow is the best way to allow stronger = authentication of the authorizing user while still allowing a limited = input device (e.g. command line) to work.
  
Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 12, 2017, at 11:22 AM, Justin Richer <jricher@mit.edu> = wrote:

=20 =20 =20

I = second the recommendation to use the device flow for this kind of system. The commandline client would print out a text string for the user to enter into their browser elsewhere.

If you can pop up a system browser then it's even = easier and you can just use the auth code flow, but it's a lot to assume that a commandline app can have that kind of capability available to it. Printing out a string? That's easy and universal. That's why I say go with the device flow.

The thing is, at the end = of the day, you need the user to authenticate to the AS if you're going to get delegated access from them. That's really the whole point of the OAuth protocol, after all. So you can either do that in a local browser of some kind (like popping a system browser), on another device (with the device flow), or you can be evil and use the username/password grant and just steal the user's credentials yourself. If it's not clear, I don't recommend that, basically ever.

 -- Justin


On 6/11/2017 11:58 PM, Aaron Parecki wrote:
=20
I've seen this done a few ways:

* The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization = flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal.
* The command line app can launch an HTTP server = on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.

----
Aaron Parecki
aaronparecki.com
@aaronpk


On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <bburke@redhat.com> wrote:
Has anybody done any spec work around doing oauth from command line interfaces?  We're looking for something where the = auth server can generate text-based challenges that are rendered in the console window that query for simple text input over possibly multiple requests.  I'm not talking about = Resource Owner or Client Credentials grant.  The command line = client may not know the credential types required for a successful token request. It would be easy to write a simple protocol, but I'd rather just do something around any existing internet draft or rfc that somebody has put some thought into.  Hope I'm making sense here.

Thanks,

Bill Burke

Red Hat

_______________________________________________
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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQc= xBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&a= mp;m=3Dj2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=3DeodAcEm9pUWInxQ= kdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=3D

= --Apple-Mail=_51CFB8D3-007B-4FFF-B89A-AAB80FEB2A5C-- From nobody Mon Jun 12 12:00:01 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3CB129A97 for ; Mon, 12 Jun 2017 12:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wbERoqJXqsb for ; Mon, 12 Jun 2017 11:59:55 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 0E8BE129789 for ; Mon, 12 Jun 2017 11:59:55 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id m47so25122048iti.0 for ; Mon, 12 Jun 2017 11:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0lg8rWHZEOdEw5f+JpvHm9pPpCGK5Aw+iikEM27goUw=; b=LYGVYEC+Ywu42gRHLGM2dnd9y4720ASUH3+mFTZmfMXsBXfPaZnv/IVAA3YYAWMgpV iMkOzvgqemZyWo4GJ5p6UQCfdXp0crSTo2nfp+OWaZnFle2S+2OEk4vtBF5bR+EXreaa mRL6SIsj0kHwydYuStKAkWHxNoonFPMV27Xm4ufg4ipxHk8QtOGUnt4GJb/8cBPt+Bsm zQY15/AoP+iNgzhu3jAt9hU5o730t4gqC1BfMigmZgW+sBTtc990fsz4N94pK0GpVjPS 3sHW+QWWxsUXjb8Fibu3GMYDUUPPHm2Iahq2zgfFxJiHVoBm+BNa5qRKFknReh5dLp0V xGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0lg8rWHZEOdEw5f+JpvHm9pPpCGK5Aw+iikEM27goUw=; b=kP5NyFeug1zWUvZ4NvAW+Sqrp7M897T4EpSlm3ctrXLyqenn58/pCVLV+aIib5x6Dw tMjGXc4Oq/joTV+BNSJyEA7Kc6X3KtnrgSOxKpuwDNi4dNWJhDQ7ANibsxF5xWtW0VAK aj+ZNkfH0WNNIVxVF9al6T9dMLANeyUQwxbFPhtl5t0Cjdn1x+qQ4BtC9Jh1Ib80fZD+ 851OhEp8Rg4DpANtT7eCmzm1gNa8P2WukAj2dolvch0r5BWGCyCsoylk9+JoPhwN101c GXN6WR+QQesSpcKBtLhB7k5kAA9g7YiqOXOSyJ1mKASOs/qePp3ZQoIj6UaHmUDzFhx1 eYtQ== X-Gm-Message-State: AODbwcCDB/Jyi2cNEkqmx3oH3a4Zn7hbPPTQ7JhoL+jWLJX/9Wj6YqAF /OjGwD46lZLlxWciFYlybty9f4H0dw== X-Received: by 10.36.82.82 with SMTP id d79mr13303351itb.90.1497293994272; Mon, 12 Jun 2017 11:59:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.30.74 with HTTP; Mon, 12 Jun 2017 11:59:33 -0700 (PDT) In-Reply-To: References: <83057e12-1d09-1b2c-88a4-b1918c9a0b5b@mit.edu> From: Dick Hardt Date: Mon, 12 Jun 2017 11:59:33 -0700 Message-ID: To: Phil Hunt Cc: Justin Richer , OAuth WG Content-Type: multipart/alternative; boundary="001a11449c0aa75aa70551c7ecd8" Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 19:00:00 -0000 --001a11449c0aa75aa70551c7ecd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to the device flow if you can't pop open a system browser. If you can pop open a system browser, then a more standard flow is a better CX. On Mon, Jun 12, 2017 at 11:34 AM, Phil Hunt wrote: > +1 > > The point of OAuth is to break away from using UID/Password (basic auth). > > > The device flow is the best way to allow stronger authentication of the > authorizing user while still allowing a limited input device (e.g. comman= d > line) to work. > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Jun 12, 2017, at 11:22 AM, Justin Richer wrote: > > I second the recommendation to use the device flow for this kind of > system. The commandline client would print out a text string for the user > to enter into their browser elsewhere. > > If you can pop up a system browser then it's even easier and you can just > use the auth code flow, but it's a lot to assume that a commandline app c= an > have that kind of capability available to it. Printing out a string? That= 's > easy and universal. That's why I say go with the device flow. > > The thing is, at the end of the day, you need the user to authenticate to > the AS if you're going to get delegated access from them. That's really t= he > whole point of the OAuth protocol, after all. So you can either do that i= n > a local browser of some kind (like popping a system browser), on another > device (with the device flow), or you can be evil and use the > username/password grant and just steal the user's credentials yourself. I= f > it's not clear, I don't recommend that, basically ever. > > -- Justin > > On 6/11/2017 11:58 PM, Aaron Parecki wrote: > > I've seen this done a few ways: > > * The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device- > flow > > which is what you see on browserless devices like the Apple TV logging in > to a cable provider from your phone. A short code is generated and > displayed on the screen, you launch a browser on your phone and enter the > code. This would work just as well from the command line on the same > device. > * I've also seen apps use the authorization flow, by displaying the > authorization URL on the command line prompt and instructing the user to > open it in a browser. The redirect URI is a hosted web page that displays > the authorization code and instructs the user to paste it back at the > terminal. > * The command line app can launch an HTTP server on localhost and use tha= t > as the redirect URL for the authorization code flow. This option ends up > being the most seamless since it works like a traditional flow without an= y > special instructions to the user. > > ---- > Aaron Parecki > aaronparecki.com > > @aaronpk > > > > On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke wrote: > >> Has anybody done any spec work around doing oauth from command line >> interfaces? We're looking for something where the auth server can gener= ate >> text-based challenges that are rendered in the console window that query >> for simple text input over possibly multiple requests. I'm not talking >> about Resource Owner or Client Credentials grant. The command line clie= nt >> may not know the credential types required for a successful token reques= t. >> It would be easy to write a simple protocol, but I'd rather just do >> something around any existing internet draft or rfc that somebody has pu= t >> some thought into. Hope I'm making sense here. >> >> Thanks, >> >> Bill Burke >> >> Red Hat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBK= CX5Y > TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=3D > eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=3D > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a11449c0aa75aa70551c7ecd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to the device flow if you can't pop open a system b= rowser.=C2=A0

If you can pop open a system browser, then= a more standard flow is a better CX.


On Mon, Jun 12, 2017 at = 11:34 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
+1=C2=A0
The point of OAuth is to break away from using UID/Password= (basic auth). =C2=A0=C2=A0

The device flow is the= best way to allow stronger authentication of the authorizing user while st= ill allowing a limited input device (e.g. command line) to work.
= =C2=A0=C2=A0
Phil

Oracle = Corporation, Identity Cloud Services Architect & Standards
@i= ndependentid
phil.hunt@oracle.com

On Jun 12, 2= 017, at 11:22 AM, Justin Richer <jricher@mit.edu> wrote:

=20 =20 =20

I second the recommendation = to use the device flow for this kind of system. The commandline client would print out a text string for the user to enter into their browser elsewhere.

If you can pop up a system browser then it's even easier and= you can just use the auth code flow, but it's a lot to assume that a commandline app can have that kind of capability available to it. Printing out a string? That's easy and universal. That's why = I say go with the device flow.

The thing is, at the end of the day, y= ou need the user to authenticate to the AS if you're going to get delegated access from them. That's really the whole point of the OAuth protocol, after all. So you can either do that in a local browser of some kind (like popping a system browser), on another device (with the device flow), or you can be evil and use the username/password grant and just steal the user's credentials yourself. If it's= not clear, I don't recommend that, basically ever.

=C2=A0-- Justin


On 6/11/2017 11:58= PM, Aaron Parecki wrote:
=20
I've seen this done a few ways:

* The Device Flow:=C2=A0https://tools.ietf.org/html/draft-ietf-= oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal.
* The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.

----
Aaron Parecki

On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <bburke@redhat.com> wrote:
Has anybody done any spec work around doing oauth from command line interfaces?=C2=A0 We're looking for something where th= e auth server can generate text-based challenges that are rendered in the console window that query for simple text input over possibly multiple requests.=C2=A0 I'm not talking about Res= ource Owner or Client Credentials grant.=C2=A0 The command line clien= t may not know the credential types required for a successful token request. It would be easy to write a simple protocol, but I'd rather just do something around any existing internet draft or rfc that somebody has put some thought into.=C2=A0 Hope I'm making sense here.

Thanks,

Bill Burke

Red Hat

_______________________________________________
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<= br>OAuth@ietf.org
https://= urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx= BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwl= NKe4C_lLIGk&m=3Dj2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&a= mp;s=3DeodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=3D <= br>


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




--
=
Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on!
--001a11449c0aa75aa70551c7ecd8-- From nobody Mon Jun 12 14:38:51 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580CF12EB64 for ; Mon, 12 Jun 2017 14:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5F_D_PHw_s1 for ; Mon, 12 Jun 2017 14:38:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C286E12EB58 for ; Mon, 12 Jun 2017 14:38:48 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 55FBA83F45; Mon, 12 Jun 2017 21:38:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 55FBA83F45 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bburke@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 55FBA83F45 Received: from ovpn-116-70.phx2.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8E7EB95358; Mon, 12 Jun 2017 21:38:47 +0000 (UTC) To: David Waite , "Hollenbeck, Scott" Cc: "aaron@parecki.com" , "oauth@ietf.org" References: <831693C2CDA2E849A7D7A712B24E257F73E441C6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: Bill Burke Message-ID: Date: Mon, 12 Jun 2017 17:38:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 12 Jun 2017 21:38:48 +0000 (UTC) Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:38:50 -0000 On 6/12/17 12:20 PM, David Waite wrote: > FYI, A few years ago I did a demonstration on OpenID Connect at Cloud > Identity Summit using a collection of bash scripts and command-line > utilities (nc, jq). I used the macOS system command ‘open’ to launch a > browser, and netcat to field the response as a poor man’s HTTP > endpoint. The code for that presentation is at > https://github.com/dwaite/Presentation-Code-OpenID-Connect-Dynamic-Client-Registration > > > A few options for the user challenge/consent portion of the > authentication are: > > - use non-HTML request/response API (around some custom MIME type) to > drive a user agent through the authentication/scope approval/etc > stages of your AS This is the option I'm interested in. Something simple around 401 challenges, text/plain mime type, and simple stdin processing. I"ll post what I'm thinking of if its appropriate. A colleague pointed me to SASL + HTTP [1], but not sure if that's what I'm looking for. Thanks everybody, Bill [1] https://tools.ietf.org/html/draft-nystrom-http-sasl-09 From nobody Thu Jun 15 11:18:54 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73645120726 for ; Thu, 15 Jun 2017 11:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd-Gm1bkbKR2 for ; Thu, 15 Jun 2017 11:18:50 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 C99311286B1 for ; Thu, 15 Jun 2017 11:18:49 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id v7so10473869ywc.2 for ; Thu, 15 Jun 2017 11:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tXDrfgypbMEY9c/SikEX9U+dpwt7aVPvoevUZqsJkU0=; b=nKSyGmt/LfNlCWvwz9O922sUtK8Fddqi98ROvClD4KX5ZlFeGCCJubVvr6C9RdQsIO a8Q9/SFVJ8Hywqqww1uti9SfJR4lWfmV2rAMRqxcq8gcAOo3DV2GhPjtdnPwv4K2LWzp hC98tBz7/YeNHSuBFilhfsHjX+/aAMzq0odvZ3ijXIRTbSH3qxejh2b5+hv8oJOwx6xB c6uDIP46jEP5FRjlVcJ/nb0KDPVCqUAO9qdaVgQxz60i43m79spW+LUK3eAiCzY1orTH mDLpimdeBzjjaPx7Mv6HtJZto28a4YCvDWmUgGZMqx20Jvx0aD18Fupob6aiC4yOp5Rx rSsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tXDrfgypbMEY9c/SikEX9U+dpwt7aVPvoevUZqsJkU0=; b=Nq6wiDeUadtWktEKQMkYp/nnHlzwy6QQ0TQRqYJ3xVtwS0jfZr/4TIJPU9ZrXI049s albWGwzqAmd7haR5jmxghS9QvyJG3BV0YTLGG7Rre5vLvJvex7bilQ5+ub1484o01PpO WfZB18NU7dM3/8jtjITGKsu3kpdxRtMqK4a385zXMGad4TvyuV6Cri0nVWb95Sn8nsl+ 11HJ0/5nztFlFlU2QegepssAREevgwiMD7FydysS4MAj+xhwmesjZTaaSFdJ7GRztTH9 4OUbv4sjSwSwdCF6qYBEUf49KEBwAMeOg/U2Eg+1uzDTL/4Od6M4YUbv8uwhgDwbC+zT ITVw== X-Gm-Message-State: AKS2vOzFgdi9JAIMOySCeiUnfPLBUTLMz5pU8MQOoKgz/17I1AEmts+P JNApiS+JRYhwnlQdgKXjA8yxYvu10g== X-Received: by 10.129.120.142 with SMTP id t136mr5231754ywc.127.1497550729060; Thu, 15 Jun 2017 11:18:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.67 with HTTP; Thu, 15 Jun 2017 11:18:48 -0700 (PDT) In-Reply-To: References: <149583038439.8608.6889631754413770370@ietfa.amsl.com> From: Takahiko Kawasaki Date: Fri, 16 Jun 2017 03:18:48 +0900 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c0b15a83d4041055203b3fd" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 18:18:52 -0000 --94eb2c0b15a83d4041055203b3fd Content-Type: text/plain; charset="UTF-8" Dear Brian, Thank you for having fixed it. I don't think my name should be listed in the document just for this, though. It's too unbalanced considering others' contribution... Best, Taka 2017-06-12 20:57 GMT+09:00 Brian Campbell : > Thanks Takahiko, mentioning it on the list is enough. I've fixed it in > the editors' draft https://github.com/ietf-oauth-mtls/i-d/commit/ > c6725e30dd1dc2f77aa293bce7fd1849713ed406 > > On Mon, Jun 12, 2017 at 5:33 AM, Takahiko Kawasaki > wrote: > >> Hello, >> >> I'm sorry for this FAQ but where can I make comments for the draft of >> "Mutual TLS Profiles for OAuth Clients"? >> >> I found a trivial editorial issue in the last paragraph in "3. Mutual TLS >> Sender Constrained Resources Access". The second 'that' in "... verify that >> the that certificate matches ..." should be removed (= that part should be >> "... verify that the certificate matches ..."). Is it enough to mention it >> in this mailing list like this? >> >> Best Regards, >> Takahiko Kawasaki >> >> 2017-05-27 5:34 GMT+09:00 Brian Campbell : >> >>> A new draft of "Mutual TLS Profiles for OAuth Clients" has been published. The changes from the previous version are summarized below. >>> >>> >>> draft-ietf-oauth-mtls-01 >>> >>> o Added more explicit details of using RFC 7662 token introspection >>> with mutual TLS sender constrained access tokens. >>> o Added an IANA OAuth Token Introspection Response Registration >>> request for "cnf". >>> o Specify that tls_client_auth_subject_dn and >>> tls_client_auth_root_dn are RFC 4514 String Representation of >>> Distinguished Names. >>> o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. >>> o Changed the text in the Section 3 to not be specific about using a >>> hash of the cert. >>> o Changed the abbreviated title to 'OAuth Mutual TLS' (previously >>> was the acronym MTLSPOC). >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Fri, May 26, 2017 at 2:26 PM >>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt >>> To: i-d-announce@ietf.org >>> Cc: oauth@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol of the IETF. >>> >>> Title : Mutual TLS Profiles for OAuth Clients >>> Authors : Brian Campbell >>> John Bradley >>> Nat Sakimura >>> Torsten Lodderstedt >>> Filename : draft-ietf-oauth-mtls-01.txt >>> Pages : 12 >>> Date : 2017-05-26 >>> >>> Abstract: >>> This document describes Transport Layer Security (TLS) mutual >>> authentication using X.509 certificates as a mechanism for both OAuth >>> client authentication to the token endpoint as well as for sender >>> constrained access to OAuth protected resources. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-01 >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-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/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --94eb2c0b15a83d4041055203b3fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian,

Thank you for having fixed = it.

I don't think my name should be listed in = the document just for this, though. It's too unbalanced considering oth= ers' contribution...

Best,
Taka


2017-06-12 20:57 GMT+09:00 Brian Campbell <bcampbell@pingide= ntity.com>:
Thanks Takahiko, mentioning it on the list is enou= gh. I've fixed it in the editors' draft https://github.com/ietf-oauth-mtls/i-d/commit/c672= 5e30dd1dc2f77aa293bce7fd1849713ed406

On Mon, Jun 12= , 2017 at 5:33 AM, Takahiko Kawasaki <daru.tk@gmail.com> wro= te:
Hello,

I'= ;m sorry for this FAQ but where can I make comments for the draft of "= Mutual TLS Profiles for OAuth Clients"?

I found a trivial edito= rial issue in the last paragraph in "3. Mutual TLS Sender Constrained = Resources Access". The second 'that' in "... verify that = the that certificate matches ..." should be removed (=3D that part sho= uld be "... verify that the certificate matches ..."). Is it enou= gh to mention it in this mailing list like this?

Best Regards,
Ta= kahiko Kawasaki

2017-05-27 5:34 GMT+09:00 Brian Campbell <bcampb= ell@pingidentity.com>:
A new draft of "Mutual TLS Profiles for OAuth Clients"=
 has been published. The changes from the previous version are summarized b=
elow. 

   draft-iet=
f-oauth-mtls-01

   o  Added more explicit details of using RFC 7662 token introspectio=
n
      with mutual TLS sender constrained access tokens.
   o  Added an IANA OAuth Token Introspection Response Registration
      request for "cnf".
   o  Specify that tls_client_auth_subject_dn and
      tls_client_auth_root_dn are RFC 4514 String Representation of
      Distinguished Names.
   o  Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
   o  Changed the text in the Section 3 to =
not be specific about using a
      hash of the cert.
   o  Changed the abbreviated title to 'OAuth Mutual TLS' (previous=
ly
      was the acronym MTLSPOC).



---------= - Forwarded message ----------
From: = <internet-drafts@ietf.org>
Date: Fri, May 26, 2017= at 2:26 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt=
To: i-d-anno= unce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mutual TLS Profiles for OAuth Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-26

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for bot= h OAuth
=C2=A0 =C2=A0client authentication to the token endpoint as well as for sen= der
=C2=A0 =C2=A0constrained access to OAuth protected resources.


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

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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




CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.
--94eb2c0b15a83d4041055203b3fd-- From nobody Fri Jun 16 16:58:23 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D238129536; Fri, 16 Jun 2017 16:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHfjsWVfgXWs; Fri, 16 Jun 2017 16:58:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85A7127601; Fri, 16 Jun 2017 16:58:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D4BB0B80E0C; Fri, 16 Jun 2017 16:58:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org Message-Id: <20170616235804.D4BB0B80E0C@rfc-editor.org> Date: Fri, 16 Jun 2017 16:58:04 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] RFC 8176 on Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 23:58:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8176 Title: Authentication Method Reference Values Author: M. Jones, P. Hunt, A. Nadalin Status: Standards Track Stream: IETF Date: June 2017 Mailbox: mbj@microsoft.com, phil.hunt@yahoo.com, tonynad@microsoft.com Pages: 15 Characters: 30765 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-amr-values-08.txt URL: https://www.rfc-editor.org/info/rfc8176 DOI: 10.17487/RFC8176 The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jun 16 17:50:49 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B77F124C27 for ; Fri, 16 Jun 2017 17:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIE4jjrhlPK6 for ; Fri, 16 Jun 2017 17:50:44 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0118.outbound.protection.outlook.com [104.47.37.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C69120454 for ; Fri, 16 Jun 2017 17:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vZkHFMP5yf7YKTcLPdqBBcbBb2a047XDIrx9RNN4tmY=; b=QWgAZpmUZaZ/FSEtfBDtFB7FHS5daY+obLHliIFj+Nom+zznPljf+NGVnE3bDoDT3BHTWnGSbFwbHW/lTxIrqHYCcjfVL2oyGBl3EiCUKsi/MNJKaQ+voXVr5RX4ReE1+ElHkNaBrQydeVnSzof7Bytx16kA5e1roO/bM5LHPCs= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Sat, 17 Jun 2017 00:50:43 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1199.007; Sat, 17 Jun 2017 00:50:43 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Authentication Method Reference Values is now RFC 8176 Thread-Index: AdLm/SQFxEk7tkh9S16dsit8Wi5rwg== Date: Sat, 17 Jun 2017 00:50:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-16T17:50:41.5533635-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:b::3fc] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0630; 7:5vMRIepUXzZPWcFjb1JC96nVZVmtANPTkMFVuPCeyWHTu5sU6eRlzRvJU1lZqclQTPia8XYzk0QkioFUzg/vWTZtS2Ban2RYELxuWuKSFhpz4r+uKilrkrK8qUv1RnMVIXvaXak5A0AjTAsjqHFYj+EtJnZXP0gejQ4KEY0OLVpgaXSMHH0AA9C1G5tKPt+1XHdr7llcprQkndqqFA2iGNl5Pfb+LoY+dhMPg5LpvNjLMrKfCm7qrEfUe1II7hMpc9EGytCSz2rmX4SOIa1yGuTTppgaWWwzadLWH8k5yVIP0vGZBdYEe4ujCz+dTWhvXmpsMRIlrrDFJ82edP89aBIBdsd0HCV/F2DGT4E7ZmfircK/3SHsk96ZCau0zp+BfulXUblg7wmQdj+vKKduCI4y3Wa+WL9R6XpF/NNw1wWbv3mpxXV2Xc8Q6owD4qFam/4LDhW3fOHlAYmeO3HANdxzDcGe9C+07xAUQBQHEJlFrwSpTQPfSAXeyI2FhCqndfS1rGCOmaOYZ4NmSFYZRfL6SzPQ/6iAOjPh/lYd0IUfNcNauVOeqv365BFjwC8P2fMLg9jTkd6xddJ8AZyY760FmqOX24w8p7e6r7LLa3SyfE5+7xxQTxahpD4koHmu3ntNZklv85CpZ3/IGlD0nOlmUeMncz+oTg6EVr2rKIu3PSKMwIJxrefwXDBIdToAMvsfP5CjKrFJ6p6uelL4llYK1UIZtQhFuhmpF8uD4als/kHmluE94XMxnnlizsINxRrcZXZFiquNgZnvKANErNhurFKernj57Em5OIr0jwhsRWJuHZJ1yVdkYkh3Ga1I x-ms-office365-filtering-correlation-id: 4421097d-ef69-480a-92f9-08d4b51ae1ec x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:CY4PR21MB0630; x-ms-traffictypediagnostic: CY4PR21MB0630: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0630; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0630; x-forefront-prvs: 034119E4F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(209900001)(3660700001)(77096006)(7696004)(86612001)(5005710100001)(86362001)(81166006)(6916009)(8676002)(8990500004)(10090500001)(6506006)(122556002)(478600001)(189998001)(1730700003)(8936002)(606005)(2906002)(33656002)(54356999)(50986999)(5660300001)(7906003)(72206003)(551544002)(2351001)(7736002)(6436002)(74316002)(2900100001)(14454004)(9686003)(99286003)(102836003)(6116002)(53936002)(110136004)(54896002)(55016002)(236005)(966005)(3280700002)(38730400002)(10290500003)(6306002)(25786009)(5630700001)(53376002)(790700001)(5640700003)(2501003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0630; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504ED00B9D8A5381A19AE0EF5C60CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2017 00:50:42.8606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0630 Archived-At: Subject: [OAUTH-WG] Authentication Method Reference Values is now RFC 8176 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 00:50:47 -0000 --_000_CY4PR21MB0504ED00B9D8A5381A19AE0EF5C60CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Authentication Method Reference Values specification is now RFC 8176. The abstract describes the spec= ification as: The amr (Authentication Methods References) claim is defined and registered= in the IANA "JSON Web Token Claims" registry, but no standard Authenticati= on Method Reference values are currently defined. This specification establ= ishes a registry for Authentication Method Reference values and defines an = initial set of Authentication Method Reference values. The specification defines and registers some Authentication Method Referenc= e values such as the following, which are already in use by some Google and= Microsoft products and OpenID specifications: * "face" - Facial recognition * "fpt" - Fingerprint * "hwk" - Proof-of-possession of a hardware-secured key * "otp" - One-time password * "pin" - Personal Identification Number * "pwd" - Password * "swk" - Proof-of-possession of a software-secured key * "sms" - Confirmation using SMS * "user" - User presence test * "wia" - Windows Integrated Authentication See https://www.iana.org/assignments/authentication-method-reference-values= / for the full list of registered values. Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and William Denniss, all of= whom substantially contributed to the specification. Thanks also to the O= Auth working group members, chairs, area directors, and other IETF members = who helped refine the specification. -- Mike P.S. This announcement was also posted at http://self-issued.info/?p=3D170= 1 and as @selfissued. --_000_CY4PR21MB0504ED00B9D8A5381A19AE0EF5C60CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Authentication Method Reference Values specifica= tion is now RFC 8176.  = The abstract describes the specification as:

 

The amr (Authentication Methods References) claim is defined an= d registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defin= ed. This specification establishes a registry for Authentication Method Ref= erence values and defines an initial set of Authentication Method Reference= values.

 

The specification defines and registers some Authent= ication Method Reference values such as the following, which are already in= use by some Google and Microsoft products and OpenID specifications:<= /o:p>

  • “face” – Facial recognition
  • “fpt” – Fingerpr= int
  • “hwk” – Proof-of-possession of a hardware-secure= d key
  • “otp” – One-time password
  • “pin̶= 1; – Personal Identification Number
  • “pwd” – Pa= ssword
  • “swk” – Proof-of-possession of a software-sec= ured key
  • “sms” – Confirmation using SMS
  • “user” – User presence test
  • “wia” – Windo= ws Integrated Authentication

See https://www.iana.org/assignments/authentication-method-reference-values/ for the full list of registered values.

 

Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and = William Denniss, all of whom substantially contributed to the specification= .  Thanks also to the OAuth working group members, chairs, area direct= ors, and other IETF members who helped refine the specification.

 

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

 

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

 

--_000_CY4PR21MB0504ED00B9D8A5381A19AE0EF5C60CY4PR21MB0504namp_-- From nobody Fri Jun 16 19:25:43 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D39E12E854 for ; Fri, 16 Jun 2017 19:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1wlQA3SdnFb for ; Fri, 16 Jun 2017 19:25:39 -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 0F3FC126CC7 for ; Fri, 16 Jun 2017 19:25:39 -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 v5H2Pb3t001782 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Jun 2017 02:25:38 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v5H2Pbgr007403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Jun 2017 02:25:37 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v5H2PZLm027581; Sat, 17 Jun 2017 02:25:36 GMT Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Jun 2017 19:25:35 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-1FBD6D2D-90BC-432A-8B19-8E3464045E46 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Fri, 16 Jun 2017 19:25:33 -0700 Cc: "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: Mike Jones X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [OAUTH-WG] Authentication Method Reference Values is now RFC 8176 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 02:25:41 -0000 --Apple-Mail-1FBD6D2D-90BC-432A-8B19-8E3464045E46 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Mike! Phil > On Jun 16, 2017, at 5:50 PM, Mike Jones wrot= e: >=20 > The Authentication Method Reference Values specification is now RFC 8176. = The abstract describes the specification as: > =20 > The amr (Authentication Methods References) claim is defined and registere= d in the IANA "JSON Web Token Claims" registry, but no standard Authenticati= on Method Reference values are currently defined. This specification establi= shes a registry for Authentication Method Reference values and defines an in= itial set of Authentication Method Reference values. > =20 > The specification defines and registers some Authentication Method Referen= ce values such as the following, which are already in use by some Google and= Microsoft products and OpenID specifications: > =E2=80=9Cface=E2=80=9D =E2=80=93 Facial recognition > =E2=80=9Cfpt=E2=80=9D =E2=80=93 Fingerprint > =E2=80=9Chwk=E2=80=9D =E2=80=93 Proof-of-possession of a hardware-secured k= ey > =E2=80=9Cotp=E2=80=9D =E2=80=93 One-time password > =E2=80=9Cpin=E2=80=9D =E2=80=93 Personal Identification Number > =E2=80=9Cpwd=E2=80=9D =E2=80=93 Password > =E2=80=9Cswk=E2=80=9D =E2=80=93 Proof-of-possession of a software-secured k= ey > =E2=80=9Csms=E2=80=9D =E2=80=93 Confirmation using SMS > =E2=80=9Cuser=E2=80=9D =E2=80=93 User presence test > =E2=80=9Cwia=E2=80=9D =E2=80=93 Windows Integrated Authentication > See https://www.iana.org/assignments/authentication-method-reference-value= s/ for the full list of registered values. > =20 > Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and William Denniss, all o= f whom substantially contributed to the specification. Thanks also to the O= Auth working group members, chairs, area directors, and other IETF members w= ho helped refine the specification. > =20 > -- Mike > =20 > P.S. This announcement was also posted at http://self-issued.info/?p=3D17= 01 and as @selfissued. > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&= r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Dc4h3kFuEtVHltGQ2Mo4qOxZU= NOdHh2wTrdydAc7z8zQ&s=3DSzWRl9usAtrZR4uccnnP_Cq3XEwz6np9UhOmTtxF8rA&e=3D=20 --Apple-Mail-1FBD6D2D-90BC-432A-8B19-8E3464045E46 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thank you Mike!

Phil
=
On Jun 16, 2017, at 5:50 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

<= blockquote type=3D"cite">

The Authentication Method Reference Values specificat= ion is now RFC 8176.  The abstract describes the= specification as:

 

Th= e amr (Authentication Methods References) claim is defined and r= egistered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently define= d. This specification establishes a registry for Authentication Method Refer= ence values and defines an initial set of Authentication Method Reference va= lues.

 

The specification defines and registers some Authenti= cation Method Reference values such as the following, which are already in u= se by some Google and Microsoft products and OpenID specifications:

  • =E2=80=9Cface=E2=80=9D =E2=80=93 Facial recognition
  • =E2=80=9Cfpt=E2=80=9D =E2=80=93 Fi= ngerprint
  • =E2=80=9Chwk=E2=80=9D =E2=80=93 Proof-of-possession of a hardwa= re-secured key
  • =E2=80=9Cotp=E2=80=9D =E2=80=93 One-time password
  • =E2=80=9Cpin= =E2=80=9D =E2=80=93 Personal Identification Number
    • pwd=E2= =80=9D =E2=80=93 Password
  • =E2=80=9Cswk=E2=80=9D =E2=80=93 Proof-of-posses= sion of a software-secured key
  • =E2=80=9Csms=E2=80=9D =E2=80=93 Confirmati= on using SMS
  • =E2=80=9Cuser=E2=80=9D =E2=80=93 User presence test
  • =E2=80=9Cwia= =E2=80=9D =E2=80=93 Windows Integrated Authentication
    • =

See https://www.iana.org/assignments/authentication-method-reference-values/= for the full list of registered values.

 

Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and W= illiam Denniss, all of whom substantially contributed to the specification. &= nbsp;Thanks also to the OAuth working group members, chairs, area directors,= and other IETF members who helped refine the specification.

 

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

 

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

 

= --Apple-Mail-1FBD6D2D-90BC-432A-8B19-8E3464045E46-- From nobody Sat Jun 17 07:24:30 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB43129AD2 for ; Sat, 17 Jun 2017 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hthzg1M1mn6R for ; Sat, 17 Jun 2017 07:24:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EA7129ACD for ; Sat, 17 Jun 2017 07:24:26 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7496F81222; Sat, 17 Jun 2017 14:24:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7496F81222 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bburke@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7496F81222 Received: from ovpn-116-55.phx2.redhat.com (ovpn-116-55.phx2.redhat.com [10.3.116.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id A5BB67ABFA; Sat, 17 Jun 2017 14:24:24 +0000 (UTC) To: Phil Hunt , Justin Richer Cc: Aaron Parecki , OAuth WG References: <83057e12-1d09-1b2c-88a4-b1918c9a0b5b@mit.edu> From: Bill Burke Message-ID: <7f013f54-3484-b15a-8dca-71209d48cede@redhat.com> Date: Sat, 17 Jun 2017 10:24:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2D6F3CCBEBCF24700D18DB8C" Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Sat, 17 Jun 2017 14:24:25 +0000 (UTC) Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 14:24:29 -0000 This is a multi-part message in MIME format. --------------2D6F3CCBEBCF24700D18DB8C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I guess the auth code flow could be used with the command line tool using the OpenID Connect "display" parameter with a value of "command-line" or "text" or something when it makes its auth request. I could go the route of defining what "command-line" display value would mean in OIDC land. Awkward from an implementation point of view, but a viable path. Quite honestly, I just dont' see how any app developer would want to require device flow. It is a bad user experience. I would even go as far to say that the device flow is an unacceptable user experience. Especially if cut and paste is not possible and the human has to enter in some kind of long cryptic code by hand. On 6/12/17 2:34 PM, Phil Hunt wrote: > +1 > > The point of OAuth is to break away from using UID/Password (basic auth). > > The device flow is the best way to allow stronger authentication of > the authorizing user while still allowing a limited input device (e.g. > command line) to work. > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Jun 12, 2017, at 11:22 AM, Justin Richer > > wrote: >> >> I second the recommendation to use the device flow for this kind of >> system. The commandline client would print out a text string for the >> user to enter into their browser elsewhere. >> >> If you can pop up a system browser then it's even easier and you can >> just use the auth code flow, but it's a lot to assume that a >> commandline app can have that kind of capability available to it. >> Printing out a string? That's easy and universal. That's why I say go >> with the device flow. >> >> The thing is, at the end of the day, you need the user to >> authenticate to the AS if you're going to get delegated access from >> them. That's really the whole point of the OAuth protocol, after all. >> So you can either do that in a local browser of some kind (like >> popping a system browser), on another device (with the device flow), >> or you can be evil and use the username/password grant and just steal >> the user's credentials yourself. If it's not clear, I don't recommend >> that, basically ever. >> >> -- Justin >> >> >> On 6/11/2017 11:58 PM, Aaron Parecki wrote: >>> I've seen this done a few ways: >>> >>> * The Device Flow: >>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow >>> >>> which is what you see on browserless devices like the Apple TV >>> logging in to a cable provider from your phone. A short code is >>> generated and displayed on the screen, you launch a browser on your >>> phone and enter the code. This would work just as well from the >>> command line on the same device. >>> * I've also seen apps use the authorization flow, by displaying the >>> authorization URL on the command line prompt and instructing the >>> user to open it in a browser. The redirect URI is a hosted web page >>> that displays the authorization code and instructs the user to paste >>> it back at the terminal. >>> * The command line app can launch an HTTP server on localhost and >>> use that as the redirect URL for the authorization code flow. This >>> option ends up being the most seamless since it works like a >>> traditional flow without any special instructions to the user. >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> >>> @aaronpk >>> >>> >>> >>> On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke >> > wrote: >>> >>> Has anybody done any spec work around doing oauth from command >>> line interfaces? We're looking for something where the auth >>> server can generate text-based challenges that are rendered in >>> the console window that query for simple text input over >>> possibly multiple requests. I'm not talking about Resource >>> Owner or Client Credentials grant. The command line client may >>> not know the credential types required for a successful token >>> request. It would be easy to write a simple protocol, but I'd >>> rather just do something around any existing internet draft or >>> rfc that somebody has put some thought into. Hope I'm making >>> sense here. >>> >>> Thanks, >>> >>> Bill Burke >>> >>> Red Hat >>> >>> _______________________________________________ >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e= >> > --------------2D6F3CCBEBCF24700D18DB8C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I guess the auth code flow could be used with the command line tool using the OpenID Connect "display" parameter with a value of "command-line" or "text" or something when it makes its auth request.  I could go the route of defining what "command-line" display value would mean in OIDC land.  Awkward from an implementation point of view, but a viable path.

Quite honestly, I just dont' see how any app developer would want to require device flow.  It is a bad user experience.  I would even go as far to say that the device flow is an unacceptable user experience.  Especially if cut and paste is not possible and the human has to enter in some kind of long cryptic code by hand.




On 6/12/17 2:34 PM, Phil Hunt wrote:
+1 

The point of OAuth is to break away from using UID/Password (basic auth).   

The device flow is the best way to allow stronger authentication of the authorizing user while still allowing a limited input device (e.g. command line) to work.
  
Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Jun 12, 2017, at 11:22 AM, Justin Richer <jricher@mit.edu> wrote:

I second the recommendation to use the device flow for this kind of system. The commandline client would print out a text string for the user to enter into their browser elsewhere.

If you can pop up a system browser then it's even easier and you can just use the auth code flow, but it's a lot to assume that a commandline app can have that kind of capability available to it. Printing out a string? That's easy and universal. That's why I say go with the device flow.

The thing is, at the end of the day, you need the user to authenticate to the AS if you're going to get delegated access from them. That's really the whole point of the OAuth protocol, after all. So you can either do that in a local browser of some kind (like popping a system browser), on another device (with the device flow), or you can be evil and use the username/password grant and just steal the user's credentials yourself. If it's not clear, I don't recommend that, basically ever.

 -- Justin


On 6/11/2017 11:58 PM, Aaron Parecki wrote:
I've seen this done a few ways:

* The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal.
* The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.

----
Aaron Parecki


On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <bburke@redhat.com> wrote:
Has anybody done any spec work around doing oauth from command line interfaces?  We're looking for something where the auth server can generate text-based challenges that are rendered in the console window that query for simple text input over possibly multiple requests.  I'm not talking about Resource Owner or Client Credentials grant.  The command line client may not know the credential types required for a successful token request. It would be easy to write a simple protocol, but I'd rather just do something around any existing internet draft or rfc that somebody has put some thought into.  Hope I'm making sense here.

Thanks,

Bill Burke

Red Hat

_______________________________________________
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=


--------------2D6F3CCBEBCF24700D18DB8C-- From nobody Sat Jun 17 07:32:03 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A809312943F for ; Sat, 17 Jun 2017 07:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36fcrQP19sGc for ; Sat, 17 Jun 2017 07:32:01 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 4AC37126B7F for ; Sat, 17 Jun 2017 07:32:01 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id r67so46058891ota.1 for ; Sat, 17 Jun 2017 07:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pe06EB2OwdsAWav5RMYZH/qrM2vzHaUNFtUB2gGRA/U=; b=Mx+CAtBgZKpW/zqvr053CxLmsBbKx5Y3/CG0AZyygGti++WAM5XNRbENwnww6XLMUO h2aIGFl+RBeQ/UC28eJS0J/D9dv2Rfz8XB393uUAB62sDu78Yz9j1XAD2leZq8vEvzgF Fn2UH2XhntWi2qOJX3Wh5Utqm6ySw4DpXV4e9pMqPoqpiltq3Dn0Kgjlo4KVus7fbCeG uh24LwmdOpD3FI7N2bovlkzcHhqJfNiaq/V5AR+xMdvsZFHTKxMKTugSfpte4ZL7LMRq scJhmREiwr2IAalrcy9lKBOMgcXQULQ3H8a6tOIAGgozxi2Na9DMnpA/ozpyMjgFEBkJ QuOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pe06EB2OwdsAWav5RMYZH/qrM2vzHaUNFtUB2gGRA/U=; b=cEmGU2G03sKurtKYChBvXdbbwXGE5LEV5rhGZyovKdJSAZ6NykZGbDRgwxitX+Uoz6 82b+uHZFaD2avPjVpQSY2hg/iu0EOfNrAvMMpWoRrhEYHekOHfDqVEf/UJ8GPplJzwy5 pTPNKXSyNgnmE2+J8FvSV1eoubzyRAEBxxjmp4r//uHsGFa9CmhqiEle+rU6+UzIoSBh eASCOTh+YuCZ1XIJY0q7lkk5AflAnifb3BMk3R6VHVHue08RpWsSu2MlE48mouajJDGp w5B3MTEGEdY8g2d+ehEvDAK0m1SRHFum+zdrz6LJorJRcgw1cd+nMbbKqU9IfRIY4YYJ lW6Q== X-Gm-Message-State: AKS2vOxY9c4ITfP8IhK7cua15ZekM0WsvqHUQb71/N3nKNvNBMgs7VyK egcP7Rp03JWEsrkqIDeObEJquBgYONPN X-Received: by 10.157.89.141 with SMTP id u13mr8069359oth.215.1497709920519; Sat, 17 Jun 2017 07:32:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.59.11 with HTTP; Sat, 17 Jun 2017 07:31:59 -0700 (PDT) Received: by 10.74.59.11 with HTTP; Sat, 17 Jun 2017 07:31:59 -0700 (PDT) From: Abedin Turjo Date: Sat, 17 Jun 2017 07:31:59 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="f40304354c58ca0a78055228c3ed" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 14:32:03 -0000 --f40304354c58ca0a78055228c3ed Content-Type: text/plain; charset="UTF-8" --f40304354c58ca0a78055228c3ed Content-Type: text/html; charset="UTF-8"
--f40304354c58ca0a78055228c3ed-- From nobody Mon Jun 19 09:03:09 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B7D12ECBE for ; Mon, 19 Jun 2017 09:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHmg_2RZd-Zy for ; Mon, 19 Jun 2017 09:03:04 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.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 27FF313153D for ; Mon, 19 Jun 2017 09:03:03 -0700 (PDT) X-AuditID: 12074425-ef5ff70000006cb7-29-5947f5b58aa9 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 58.85.27831.5B5F7495; Mon, 19 Jun 2017 12:03:01 -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 v5JG30sr032571; Mon, 19 Jun 2017 12:03:01 -0400 Received: from [10.0.3.41] (h198.196.135.40.static.ip.windstream.net [40.135.196.198]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5JG2ukx017159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2017 12:02:59 -0400 From: Justin Richer Message-Id: <5864CD7E-875C-4775-988F-3E0D2FB74F7B@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_398501EB-44E2-4AA4-BE02-B151391B7894" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 19 Jun 2017 11:02:57 -0500 In-Reply-To: <7f013f54-3484-b15a-8dca-71209d48cede@redhat.com> Cc: Phil Hunt , Aaron Parecki , "" To: Bill Burke References: <83057e12-1d09-1b2c-88a4-b1918c9a0b5b@mit.edu> <7f013f54-3484-b15a-8dca-71209d48cede@redhat.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixG6nrrv1q3ukQccec4tzq9wserfuZLQ4 +fYVm8WC+Y3sDiweS5b8ZPL4+PQWi0fDzDSP9/uusgWwRHHZpKTmZJalFunbJXBl3J66jKWg 8Qpjxc3mJtYGxs3zGLsYOTkkBEwknjxfxtbFyMUhJLCYSWLxgguMEM5GRol5n76zg1QJCVxm ktg+oRjEZhNQlZi+poWpi5GDg1fASuL5Z2aQMLNAksT6v6tYIML6Er3PweYLC5hLdOz6xQpi swB1fp6+HWwip4CdRPvq26wQraUSl16sZQKxRQSUJFb9nAB1z1wmidOr+9ggDpWVuDX7EvME Rv5ZSNbNQlgHEdaWWLbwNTOErSmxv3s5C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYUpybrFicn 5uWlFula6OVmluilppRuYgQHv4vqDsY5f70OMQpwMCrx8C547R4pxJpYVlyZe4hRkoNJSZTX djtQiC8pP6UyI7E4I76oNCe1+BCjBAezkghv0yOgHG9KYmVValE+TEqag0VJnFdcozFCSCA9 sSQ1OzW1ILUIJivDwaEkwcsHjHIhwaLU9NSKtMycEoQ0EwcnyHAeoOGfQG7hLS5IzC3OTIfI n2LU5bg3e+sXJiGWvPy8VClx3ogvQEUCIEUZpXlwc0BJS6P9yLFXjOJAbwnzeoBU8QATHtyk V0BLmICWMJ9xAVlSkoiQkmpgrJvf9Zk56eKkR1Msi7StLV8EugvO2/qE092dI9O/dU3DDyUX VoMPAkvYXux7UTj51M7UgK65ki+23np2dNnevCNTnVv9ZGUCnn06pWQtYBxvOff3+rYnu8K2 NQcsnd/ZJ1S8L+UA37bDCc6Wkziep8md0Jx5d57J7Jx2W8MTx74/XDjt+ssyOyWW4oxEQy3m ouJEAOKtFF41AwAA Archived-At: Subject: Re: [OAUTH-WG] oauth with command line clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:03:08 -0000 --Apple-Mail=_398501EB-44E2-4AA4-BE02-B151391B7894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 While it does add a vector for user error, the codes aren=E2=80=99t long = and cryptic. Most implementations are 6 or 8 characters, and it=E2=80=99s = recommended that they be case insensitive and not have ambiguous = characters (I vs 1, O vs 0). And they should be all low ASCII, even just = a subset of uppercase letters as suggested on the spec itself. These = aren=E2=80=99t authorization codes or access tokens, which are meant to = be machine-readable and high entropy.=20 =E2=80=94 Justin > On Jun 17, 2017, at 9:24 AM, Bill Burke wrote: >=20 > I guess the auth code flow could be used with the command line tool = using the OpenID Connect "display" parameter with a value of = "command-line" or "text" or something when it makes its auth request. I = could go the route of defining what "command-line" display value would = mean in OIDC land. Awkward from an implementation point of view, but a = viable path. > Quite honestly, I just dont' see how any app developer would want to = require device flow. It is a bad user experience. I would even go as = far to say that the device flow is an unacceptable user experience. = Especially if cut and paste is not possible and the human has to enter = in some kind of long cryptic code by hand. >=20 >=20 >=20 > On 6/12/17 2:34 PM, Phil Hunt wrote: >> +1=20 >>=20 >> The point of OAuth is to break away from using UID/Password (basic = auth). =20 >>=20 >> The device flow is the best way to allow stronger authentication of = the authorizing user while still allowing a limited input device (e.g. = command line) to work. >> =20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>> On Jun 12, 2017, at 11:22 AM, Justin Richer > wrote: >>>=20 >>> I second the recommendation to use the device flow for this kind of = system. The commandline client would print out a text string for the = user to enter into their browser elsewhere.=20 >>> If you can pop up a system browser then it's even easier and you can = just use the auth code flow, but it's a lot to assume that a commandline = app can have that kind of capability available to it. Printing out a = string? That's easy and universal. That's why I say go with the device = flow. >>>=20 >>> The thing is, at the end of the day, you need the user to = authenticate to the AS if you're going to get delegated access from = them. That's really the whole point of the OAuth protocol, after all. So = you can either do that in a local browser of some kind (like popping a = system browser), on another device (with the device flow), or you can be = evil and use the username/password grant and just steal the user's = credentials yourself. If it's not clear, I don't recommend that, = basically ever.=20 >>> -- Justin >>>=20 >>> On 6/11/2017 11:58 PM, Aaron Parecki wrote: >>>> I've seen this done a few ways: >>>>=20 >>>> * The Device Flow: = https://tools.ietf.org/html/draft-ietf-oauth-device-flow = which is what you see on browserless devices = like the Apple TV logging in to a cable provider from your phone. A = short code is generated and displayed on the screen, you launch a = browser on your phone and enter the code. This would work just as well = from the command line on the same device. >>>> * I've also seen apps use the authorization flow, by displaying the = authorization URL on the command line prompt and instructing the user to = open it in a browser. The redirect URI is a hosted web page that = displays the authorization code and instructs the user to = paste it back at the terminal. >>>> * The command line app can launch an HTTP server on localhost and = use that as the redirect URL for the authorization code flow. This = option ends up being the most seamless since it works like a traditional = flow without any special instructions to the user. >>>>=20 >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com = >>>> @aaronpk = >>>>=20 >>>>=20 >>>> On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke > wrote: >>>> Has anybody done any spec work around doing oauth from command line = interfaces? We're looking for something where the auth server can = generate text-based challenges that are rendered in the console window = that query for simple text input over possibly multiple requests. I'm = not talking about Resource Owner or Client Credentials grant. The = command line client may not know the credential types required for a = successful token request. It would be easy to write a simple protocol, = but I'd rather just do something around any existing internet draft or = rfc that somebody has put some thought into. Hope I'm making sense = here. >>>>=20 >>>> Thanks, >>>>=20 >>>> Bill Burke >>>>=20 >>>> Red Hat >>>>=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 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1= 0&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Dj2jP9OSVjttUWWQMazHX= MhLBvLqfXsFJB6GEOh_Mv9k&s=3DeodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=3D= = =20 >>=20 >=20 --Apple-Mail=_398501EB-44E2-4AA4-BE02-B151391B7894 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 While it does add a vector for user error, the codes aren=E2=80= =99t long and cryptic. Most implementations are 6 or 8 characters, and = it=E2=80=99s recommended that they be case insensitive and not have = ambiguous characters (I vs 1, O vs 0). And they should be all low ASCII, = even just a subset of uppercase letters as suggested on the spec itself. = These aren=E2=80=99t authorization codes or access tokens, which are = meant to be machine-readable and high entropy. 

 =E2=80=94 Justin

On Jun 17, 2017, at 9:24 AM, Bill Burke <bburke@redhat.com> = wrote:

=20

I = guess the auth code flow could be used with the command line tool using the OpenID Connect "display" parameter with a value of "command-line" or "text" or something when it makes its auth request.  I could go the route of defining what = "command-line" display value would mean in OIDC land.  Awkward from an implementation point of view, but a viable path.

Quite honestly, I just dont' see how any app = developer would want to require device flow.  It is a bad user experience.  I = would even go as far to say that the device flow is an unacceptable user experience.  Especially if cut and paste is not possible and = the human has to enter in some kind of long cryptic code by hand.




On 6/12/17 2:34 PM, Phil Hunt = wrote:
=20 +1 

The point of OAuth is to break away from using UID/Password (basic auth).   

The device flow is the best way to allow stronger authentication of the authorizing user while still allowing a limited input device (e.g. command line) to work.
  
Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 12, 2017, at 11:22 AM, Justin Richer <jricher@mit.edu> wrote:

I second the recommendation to use the device flow for this kind of system. The commandline client would print out a text string for the user to enter into their browser elsewhere.

If you can pop up a system browser = then it's even easier and you can just use the auth code flow, but it's a lot to assume that a commandline app can have that kind of capability available to it. Printing out a string? That's easy and universal. That's why I say go with the device flow.

The = thing is, at the end of the day, you need the user to authenticate to the AS if you're going to get delegated access from them. That's really the whole point of the OAuth protocol, after all. So you can either do that in a local browser of some kind (like popping a system browser), on another device (with the device flow), or you can be evil and use the username/password grant and just steal the user's credentials yourself. If it's not clear, I don't recommend that, basically ever.

 -- Justin


On 6/11/2017 11:58 PM, Aaron Parecki wrote:
I've seen this done a few = ways:

* The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal.
* The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.

=
----
Aaron Parecki
aaronparecki.com
@aaronpk


On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <bburke@redhat.com> wrote:
Has anybody done any spec work around doing oauth from command line interfaces?  We're looking for something = where the auth server can generate text-based challenges that are rendered in the console window that query for simple text input over possibly multiple requests.  I'm not = talking about Resource Owner or Client Credentials grant.  The command line client may not = know the credential types required for a successful token request. It would be easy to write a simple protocol, but I'd rather just do something around any existing internet draft or rfc that somebody has put some thought into.  Hope = I'm making sense here.

Thanks,

Bill Burke

Red Hat

_______________________________________________
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://urldefense.proofpoint.com/v2/u= rl?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_oauth&d=3DDwICAg&c=3D= RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJ= xPEivzjWwlNKe4C_lLIGk&m=3Dj2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&= amp;s=3DeodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=3D



= --Apple-Mail=_398501EB-44E2-4AA4-BE02-B151391B7894-- From nobody Wed Jun 21 12:55:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B08B1241FC for ; Wed, 21 Jun 2017 12:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD82Skk1nfkV for ; Wed, 21 Jun 2017 12:55:02 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 06F1E126C89 for ; Wed, 21 Jun 2017 12:55:02 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id u12so165978881qth.0 for ; Wed, 21 Jun 2017 12:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KyyE+uYOWMFwsjOIvdFNG5YRQ+FUaTM39wX//doP+i8=; b=ajmbtteuATRj/c2huay6bGKEADfkCNXuAcmGfMpLVOih7wAVb3ub7/J/ln8R0NHPN5 DC5ntzSunb9HseeTzBCCtXSdBXwCvwO+U+MLL6HQKzt1jdf6+4CrhJdbm6tpojH5KQB/ E/GMxc+hXD50xo43eyZP5jFXOFoucdl0foBlDxGYZa5Yx3/LU6gNs88BkOJKKQ0ifz5L 8Sp7zSblNC3++SUm5Vjkxw5Ng+RQnhcS4HK3OQrKh9ktZ4Fx7YIokW54gdeVm3fc4FC6 N3148BZHZTTezGk8IK20DSRUBEHhnZADcQjGO05ZnRQkF6gFQqFZBZxMi4iTcPMloR6B t9yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KyyE+uYOWMFwsjOIvdFNG5YRQ+FUaTM39wX//doP+i8=; b=LbKuXOBEjxI87e++GwxH9dYrSWEjkJI5yBpR1EEJ/qWXBzGlpwKoHVvDNDMpvZiX3v bHHS/X73Q44oqQFCR1WqHQAUH33f8USbhen8C9xF0i14nC+RQbiGq+nEQ5UAJV3zHbiL n/NjQOSFnvMmjH/+gKLZHxMd9+mpuiT2cs+2Cz/X03KTtvd5SWkOJUXkXwBrkXyH8efB lQJS7bm8o14dq4m8KJ0r9jxQaf3O4ngy+6aCXg2b9Xs1lL69KTQlkzOhi28ytCngSMXc FbgZJMrK1H8WP+gB3U6uaW4ESrVjNSN3WYexuVyfnFsEuwZlibXzChg1DqOaCJ6esxBO EpwQ== X-Gm-Message-State: AKS2vOw3bmzBMSFGaui8vmC8tkFq/Mnrc75iIH7wOCszC7aWXOjDRPJo geghljJYGz64pe+88YrwdLFhJAYECQ== X-Received: by 10.200.34.55 with SMTP id o52mr43283759qto.67.1498074901203; Wed, 21 Jun 2017 12:55:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Wed, 21 Jun 2017 19:54:49 +0000 Message-ID: To: Hannes Tschofenig , "oauth@ietf.org" Cc: Hannes Tschofenig Content-Type: multipart/alternative; boundary="001a114108de554eef05527dbe9e" Archived-At: Subject: Re: [OAUTH-WG] Potential uses of PoP keys in CBOR Web Tokens (CWTs) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:55:04 -0000 --001a114108de554eef05527dbe9e Content-Type: text/plain; charset="UTF-8" So, I have finally started to put the tip of my foot into IoT world and so I have no actual product or service, but PoP keys for CWT should be useful for severely constrained devices. We have seen so many instances of token interception and replay in IoT sphere. PoP keys in CBOR should help mitigate it. Nat On Tue, Jun 13, 2017 at 3:19 AM Hannes Tschofenig wrote: > Hi all, > > RFC 7800 defines how to communicate Proof of Possession (PoP) keys for > JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) > draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of > the JSON/JOSE JWT spec. > > The ACE working group is planning to also define a CBOR/COSE equivalent > of RFC 7800 and is interested in knowing how you might use CBOR > proof-of-possession keys for CWTs. > > Please drop us a message if you are using CBOR PoP keys for CWTs. We > would like to learn more about your usage. > > Ciao > Hannes & Kepeng > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation --001a114108de554eef05527dbe9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, I have finally started to put the tip of my foot into = IoT world and so I have no actual product or service, but PoP keys for CWT = should be useful for severely constrained devices. We have seen so many ins= tances of token interception and replay in IoT sphere. PoP keys in CBOR sho= uld help mitigate it.=C2=A0

Nat

On Tue, Jun 13, 2017 at 3:19 AM Hannes Tschofeni= g <hannes.tschofenig@gmx.ne= t> wrote:
Hi all,

RFC 7800 defines how to communicate Proof of Possession (PoP) keys for
JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT)
draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of
the JSON/JOSE JWT spec.

The ACE working group is planning to also define a CBOR/COSE equivalent
of RFC 7800 and is interested in knowing how you might use CBOR
proof-of-possession keys for CWTs.

Please drop us a message if you are using CBOR PoP keys for CWTs. We
would like to learn more about your usage.

Ciao
Hannes & Kepeng

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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a114108de554eef05527dbe9e-- From nobody Wed Jun 21 13:01:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEA81293E1 for ; Wed, 21 Jun 2017 13:01:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBlvkb_nICnb for ; Wed, 21 Jun 2017 13:01:20 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518FD128D2E for ; Wed, 21 Jun 2017 13:01:20 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id t87so10460090ioe.0 for ; Wed, 21 Jun 2017 13:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8HocC5bdb3OjGgR/nqk1m8jJNGt1s0tNBbAth3EEoRc=; b=q1IwwS9ozCc/aifZ76IW+dXi3SOaIwxrH1wwIdbFLEgo1ZSN+idtK1XxtUEB1SeQdc uyezTJGzRmb71zIt5GVGYdz8AotThxBILvrnsEP2Es7XgMYlcyhIwFWyFTEJKNT5J+BS Pl9RSsDijDd/gtkEjI9iz1YdxXIv1PsrJwKIYz7rNySWB4SKVfKypI/bi8DxEq+3FUmO PgZKtT1V9C6ud6WklLaMO9fbJklACcIqB8BfLUF+YYAoJQ7jT2J97VBjA1JMin17A4u0 tMysMx8iCSIPkzpfPUp+VfDTMzSrkh3XW4CqtCP1S+wNSaQg0ksAl/1Ob37lvHtVQLCx NTkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8HocC5bdb3OjGgR/nqk1m8jJNGt1s0tNBbAth3EEoRc=; b=T31SEsfmVCXmvCeIFkS4lHumf0vTjauUfDHFb85+iAybMc34jHNOG5n0zMkHJbSYlx FJ29Z8bzbVyF8lhCEUh0Rqyi8u95m02Fkfc7du4b4oobEMVQYSPaOY+IQitroPPUfQvm 9jC5emtUR5oui6Vcq5z/bwW2bEhlMv0+spXeb0xGce26CF3IPsLrKzDFzpIBB/HRCDN5 Fyp3h68L6vs/TRSOMLQJRDxjmOA8HlDg66A42pYiS7mkJUEUCXXwj4tgsMFGjgOEsHuc Jgk4thpP7N6Xcbo6Eu5v5fFwZ1/fsZEZsYGbiMYDR5Dw09jRxAc6+QssbENF3a7D+Vup lHuw== X-Gm-Message-State: AKS2vOzSHTBgAYJL+adh6QYkwyzg+xQOT0eUFKhKAn7UK3MrsUfOYLJR DJSRu934VCW2LzzUOwRgNw== X-Received: by 10.107.134.91 with SMTP id i88mr34465968iod.53.1498075278103; Wed, 21 Jun 2017 13:01:18 -0700 (PDT) Received: from [10.150.72.61] ([208.59.64.22]) by smtp.gmail.com with ESMTPSA id o197sm1751930ioe.46.2017.06.21.13.01.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 13:01:16 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: John Bradley In-Reply-To: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> Date: Wed, 21 Jun 2017 15:01:15 -0500 Cc: "Ace@ietf.org" , Hannes Tschofenig , Kepeng Li , IETF OAUTH Message-Id: <5C392517-F427-4B32-8B9C-D42E4A095CC4@ve7jtb.com> References: <3675935b-c09d-8b34-c439-b0c5405a00d5@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ecd98e5153405527dd477" Archived-At: Subject: Re: [OAUTH-WG] [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:01:23 -0000 --001a113ecd98e5153405527dd477 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t have any deployments yet, but am changing companies in = July and can see some future use cases for POP CWT around Web = Authentication. POP for JWT is taking off and Ping has implementations of that. It would be beneficial if we could maintain the same confirmation = =E2=80=9Ccnf=E2=80=9D semantic between JWT and CWT. I suspect that there are going to be gateways and mixed environments, so = it will reduce confusion. If you are asking about specific confirmation methods you need to give = me a bit of time to swap some of this into my head. The high level semantic of a confirmation element should be the same but = even in JWT there are different methods and information that needs to be = propagated depending on the application eg key hash vs DN vs encrypted = symmetric key. John B. > On Jun 12, 2017, at 1:19 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > RFC 7800 defines how to communicate Proof of Possession (PoP) keys for > JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) > draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of > the JSON/JOSE JWT spec. >=20 > The ACE working group is planning to also define a CBOR/COSE = equivalent > of RFC 7800 and is interested in knowing how you might use CBOR > proof-of-possession keys for CWTs. >=20 > Please drop us a message if you are using CBOR PoP keys for CWTs. We > would like to learn more about your usage. >=20 > Ciao > Hannes & Kepeng >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --001a113ecd98e5153405527dd477 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIAFpQpRlRzSSmJ71yw+U5VfMibul Q3GKbs0VY2vRJE1jMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDYyMTIwMDExOVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQB6OzTqyvYGZUYn4BVgyXQzhFnuLrFuGDfeqCSkIOXZ/NQu k4FwtJNvjqIZskjyW24S3tP1m5ATbKR6lHV1304pDfsVzxSABygbFHBCCrXvu/OUbGyDZpETCsIT KugtIq+gSGTN98hY24JD85OJT+njNuL6cNUF+Lac/2oA1zxRa+wv9cO0dkqYOmsIwamvWjehSXVI 1Xwk+J08W/SaNH72GswX0RrCApka6OxMUtXDa6FeLITgx/wv69T5COlGhoTy635Pt2qR6moV2Y3f SB0mMx83IN5GRI1Y/b2rhVx8roWGRFgDP6/kBNcaAh5u9tfEy1kjsNqsgTE0WLzPVR2I --001a113ecd98e5153405527dd477-- From nobody Fri Jun 23 03:51:23 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDD5128B88; Fri, 23 Jun 2017 03:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6eE0OywHBTZ; Fri, 23 Jun 2017 03:51:11 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F2B1200ED; Fri, 23 Jun 2017 03:51:10 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 088677803A5; Fri, 23 Jun 2017 12:51:08 +0200 (CEST) To: saag@ietf.org, OAuth WG , IETF Tokbind WG References: <8d869aa1-568e-788f-b8f9-b056fc5d771c@KingsMountain.com> <14050b8e-6cd9-9be7-6a1a-3d8cbe1f19cf@free.fr> From: Denis Message-ID: Date: Fri, 23 Jun 2017 12:51:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <14050b8e-6cd9-9be7-6a1a-3d8cbe1f19cf@free.fr> Content-Type: multipart/alternative; boundary="------------2B9F9D64C442E497FC835ED4" Content-Language: en-US Archived-At: Subject: [OAUTH-WG] New Special Publication 800-63-3 "Digital Identity Guidelines" Suite published X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:51:14 -0000 This is a multi-part message in MIME format. --------------2B9F9D64C442E497FC835ED4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I also read section 8 (Security) from NIST Special Publication 800-63C (Digital Identity Guidelines). See: https://pages.nist.gov/800-63-3/sp800-63c.html Section 8.1 states:* * *"*For the purpose of these types of threats, any authorized parties who attempt to exceed their privileges are considered attackers". Section 9.3 identifies a specific use case: "In some instances, an RP does not require a full value of an attribute. For example, an RP may need to know whether the subscriber is over 13 years old, but has no need for the full date of birth". However, Bob who is over 13 might attempt to forward an assertion that he legitimately obtained from an IdP to Alice who is less than 13. This is a collusion attack that has been named : the ABC attack (Alice and Bob Collusion attack). The first description of this attack is available at: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html Such a threat or attack is not identified in this NIST document and hence no mitigation mechanism is being proposed. Access token binding protection methods developed either by the Token Binding WG or by the OAuth WG do not allow to counter the ABC attack. Either the legitimate user (e.g. Bob) can provide his key to another user (e.g. Alice), or if it can't (e.g. because it is protected by a secure element) he sends requests to his secure element to perform the cryptographic computations that the other user (e.g. Alice) needs. The RP will be unable to know which piece of software or hardware has performed the cryptographic computations. There are two ways to counter this threat: -either to include into the assertion a set of attributes that allows to uniquely identify the user (e.g. name, first name and other attributes) but which is against both data minimization privacy principles and unlinkability privacy principles, -or to use secure elements that allow to only include an attribute like "over 13" into the assertion and which are able to defeat the ABC attack. On July 13, at the OAuth Security Workshop 2017that will take place in Zürich, I will present two methods using secure elements while preserving the user's privacy that are able to defeat the ABC attack. The title of this presentation is : " A privacy by design eID scheme supporting Attribute-based Access Control (ABAC)". See: https://zisc.ethz.ch/oauth-security-workshop-2017/ Denis PS. This email is also posted to the OAuth WG mailing list and the the Token Binding mailing list. Sorry for duplications. > Thank you for providing the links. I read in particular section 5.2 > (Privacy Requirements) from > NIST Special Publication 800-63C (Digital Identity Guidelines) which > is reproduced below : > > > (See: https://pages.nist.gov/800-63-3/sp800-63c.html) > > > 5.2 Privacy Requirements > > Federation involves the transfer of personal attributes from a third > party that is not otherwise involved > in a transaction — the IdP. Federation also potentially gives the IdP > broad visibility into subscriber activities. > Accordingly, there are specific privacy requirements associated with > federation. > > Communication between the RP and the IdP could reveal to the IdP where > the subscriber is conducting a transaction. > Communication with multiple RPs allows the IdP to build a profile of > subscriber transactions that would not have existed > without federation. This aggregation could enable new opportunities > for subscriber tracking and use of profile information > that do not always align with subscribers’ privacy interests. > > The IdP SHALL NOT disclose information on subscriber activities at an > RP to any party, nor use the subscriber’s information > for any purpose other than federated authentication, related fraud > mitigation, to comply with law or legal process, or in the case of a > specific user request, to transmit the information. > > The IdP SHOULDemploy technical measures, such as the use of pairwise > pseudonymous identifiers described in Section 6.3 > > or privacy-enhancing cryptographic protocols, to provide unlinkability > and discourage subscriber activity tracking and profiling. (...) > > From the point of view of human users, this requirement ("SHALL NOT") > and this recommendation ("SHOULD") are not satisfactory, > since IdPs would be in a position to *act as Big Brother*. > > The right requirement should be: > > The IdP SHALL NOT be able to know where the subscribers are conducting > transactions. > > > This has major implications on other parts of these documents. > > Denis > >> Of possible interest... >> >> [congrats to Jim Fenton and Paul Grassi] >> >> >> >> SP 800-63-3 Digital Identity Guidelines >> SP 800-63A Enrollment and Identity Proofing >> SP 800-63B Authentication and Lifecycle Management >> SP 800-63C Federation and Assertions >> >> >> On 6/22/17, 7:33 AM, "National Institute of Standards and Technology >> (NIST)" wrote: >> >> Mic Drop — Announcing the New Special Publication 800-63 Suite! >> 06/22/2017 10:02 AM EDT >> >> >> >> More than a year in the making, after a large, cross-industry effort, >> we are proud to announce that the new Special Publication (SP) 800-63 >> IS. NOW. FINAL. With your help, Electronic Authentication Guidelines >> has evolved into Digital Identity Guidelines—a suite of documents >> covering digital identity from initial risk assessment to deployment >> of federated identity solutions. Check it out now at >> ! >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------2B9F9D64C442E497FC835ED4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I also read section 8 (Security) from NIST Special Publication 800-63C (Digital Identity Guidelines).
See: https://pages.nist.gov/800-63-3/sp800-63c.html

Section 8.1 states:

"For the purpose of these types of threats, any authorized parties who attempt to exceed their privileges
  are considered attackers".

Section 9.3 identifies a specific use case:

"In some instances, an RP does not require a full value of an attribute. For example, an RP may need to know
  whether the subscriber is over 13 years old, but has no need for the full date of birth".

However, Bob who is over 13 might attempt to forward an assertion that he legitimately obtained from an IdP to Alice
who is less than 13. This is a collusion attack that has been named : the ABC attack (Alice and Bob Collusion attack).
The first description of this attack is available at: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

Such a threat or attack is not identified in this NIST document and hence no mitigation mechanism is being proposed.

Access token binding protection methods developed either by the Token Binding WG or by the OAuth WG do not allow
to counter the ABC attack. Either the legitimate user (e.g. Bob) can provide his key to another user (e.g. Alice), or
if it can't (e.g. because it is protected by a secure element) he sends requests to his secure element to perform
the cryptographic computations that the other user (e.g. Alice) needs. The RP will be unable to know which piece of software
or hardware has performed the cryptographic computations.

There are two ways to counter this threat:

-       either to include into the assertion a set of attributes that allows to uniquely identify the user (e.g. name, first name and other attributes)
but which is against both data minimization privacy principles and unlinkability privacy principles,

-       or to use secure elements that allow to only include an attribute like "over 13" into the assertion and which are able to defeat the ABC attack.

On July 13, at the OAuth Security Workshop 2017 that will take place in Zürich, I will present two methods using secure elements while
preserving the user's privacy that are able to defeat the ABC attack. The title of this presentation is :

" A privacy by design eID scheme supporting Attribute-based Access Control (ABAC)".

See: https://zisc.ethz.ch/oauth-security-workshop-2017/

Denis


PS. This email is also posted to the OAuth WG mailing list and the the Token Binding mailing list. Sorry for duplications.


Thank you for providing the links. I read in particular section 5.2 (Privacy Requirements) from
NIST Special Publication 800-63C (Digital Identity Guidelines) which is reproduced below :

(See: https://pages.nist.gov/800-63-3/sp800-63c.html)

 

5.2 Privacy Requirements

Federation involves the transfer of personal attributes from a third party that is not otherwise involved
in a transaction — the IdP. Federation also potentially gives the IdP broad visibility into subscriber activities.
Accordingly, there are specific privacy requirements associated with federation.

Communication between the RP and the IdP could reveal to the IdP where the subscriber is conducting a transaction.
Communication with multiple RPs allows the IdP to build a profile of subscriber transactions that would not have existed
without federation. This aggregation could enable new opportunities for subscriber tracking and use of profile information
that do not always align with subscribers’ privacy interests.

The IdP SHALL NOT disclose information on subscriber activities at an RP to any party, nor use the subscriber’s information
for any purpose other than federated authentication, related fraud mitigation, to comply with law or legal process, or in the case of a specific user request, to transmit the information.

The IdP SHOULD employ technical measures, such as the use of pairwise pseudonymous identifiers described in Section 6.3
or privacy-enhancing cryptographic protocols, to provide unlinkability and discourage subscriber activity tracking and profiling. (...)

 

From the point of view of human users, this requirement ("SHALL NOT") and this recommendation ("SHOULD") are not satisfactory,
since IdPs would be in a position to act as Big Brother.

The right requirement should be:

The IdP SHALL NOT be able to know where the subscribers are conducting transactions.


This has major implications on other parts of these documents.

Denis
 
Of possible interest...

[congrats to Jim Fenton and Paul Grassi]

<https://pages.nist.gov/800-63-3/>

SP 800-63-3   Digital Identity Guidelines
SP 800-63A    Enrollment and Identity Proofing
SP 800-63B    Authentication and Lifecycle Management
SP 800-63C    Federation and Assertions


On 6/22/17, 7:33 AM, "National Institute of Standards and Technology (NIST)" wrote:

Mic Drop — Announcing the New Special Publication 800-63 Suite!
06/22/2017 10:02 AM EDT
<http://trustedidentities.blogs.govdelivery.com/2017/06/22/mic-drop-announcing-the-new-special-publication-800-63-suite/>

More than a year in the making, after a large, cross-industry effort, we are proud to announce that the new Special Publication (SP) 800-63 IS. NOW. FINAL. With your help, Electronic Authentication Guidelines has evolved into Digital Identity Guidelines—a suite of documents covering digital identity from initial risk assessment to deployment of federated identity solutions. Check it out now at <https://pages.nist.gov/800-63>!

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




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


--------------2B9F9D64C442E497FC835ED4-- From nobody Fri Jun 23 17:12:11 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7E129B45; Fri, 23 Jun 2017 17:07:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ekr@rtfm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282714.7840.17098772179837220016.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:07 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 99 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:10 -0000 Dear Hannes Tschofenig, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (1:30:00) Friday, Morning Session I 0930-1130 Room Name: Karlin III size: 60 --------------------------------------------- oauth Session 2 (1:30:00) Tuesday, Afternoon Session I 1330-1530 Room Name: Berlin/Brussels size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag core tls tokbind ace sipcore People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: Please avoid conflict with sec area BoFs. Please avoid the Friday. --------------------------------------------------------- From nobody Fri Jun 23 23:46:40 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A8128854 for ; Fri, 23 Jun 2017 23:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLfT3NoInTWg for ; Fri, 23 Jun 2017 23:46:36 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 608A8126DFB for ; Fri, 23 Jun 2017 23:46:36 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id 84so18352964ybe.0 for ; Fri, 23 Jun 2017 23:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LGfqI0KKue/St25Vdbml6+3fD7WJfKpG+JeLR+LW7e4=; b=dauABrdF6oeq8rgAEQJVi1DH55AQxj/dO1Qo8jTqdG8iCjdK0mZw6pC4mecBitUT6d I6DCC3hPwdUAIBavkDy2VDL7SD8KTXfwABQGB+cDYH9KW81UlIBQOYRZ8c5l9zc1iEes v7g+XixSaeQtDtEmlWjXpzljV6ZOp22HjgrbiXAUdhrLX5KRS9ejxWIA+YC0/1gJbeWP 8NcD034laS0KoK3gO3d2kwU0kGknwaijxYMOAoNBh0ZnRB45tySJPSu5j6k29/9uXl72 yBOvVcxd4E80VxHi0qjLKEfAzBdk3p9XgQynt+Lq/Gku52F13TXMJf9X3n6bdZs3bnr3 q4vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LGfqI0KKue/St25Vdbml6+3fD7WJfKpG+JeLR+LW7e4=; b=gt/96KYiKWeh8CfxsINtGQzPH9gi4VbulhmYOQKvmKzjqQD08UyrxUgwJAlN3cQxNY Jv/5LTWQt3NzKbH8CeUR0QzGpIP9bKNaXvCLSWRE7qixp/qVpiaSBkXsjib6YPjqab1A s+YCh054O3yCD6iTXDbehT83jchuNYmqNE9/H7SkVQ6Gaj7klyjZgyUsENjvS1dePdJG 9j2r5oNJCn3gGFNr69XRCEWOh9kceQoyB7uQQGz1UWXdAkS3oeHtjX1N+aVOvWGNIRCE 5ucrj2NHtJ2geBRmGlxZHDiOkno7XJs3UEmPSCIL0DmCrIgG41/5EM1CVGAmocL+Gx/I vRCQ== X-Gm-Message-State: AKS2vOwf5brwnFG4zC24bqj95lvsQwruxxkbLgAVtDAhord0QgbNl9RX eZahOLWn7C20XGhhX8dPQPovUsP0OQ== X-Received: by 10.37.54.4 with SMTP id d4mr9139788yba.33.1498286795677; Fri, 23 Jun 2017 23:46:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.67 with HTTP; Fri, 23 Jun 2017 23:46:35 -0700 (PDT) In-Reply-To: References: <149063228392.30557.3815696692412964113@ietfa.amsl.com> From: Takahiko Kawasaki Date: Sat, 24 Jun 2017 15:46:35 +0900 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c1b0ede3a66380552af14a2" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-binding-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 06:46:39 -0000 --94eb2c1b0ede3a66380552af14a2 Content-Type: text/plain; charset="UTF-8" Dear Brian, Just a small editorial issue on the 4th line in the 2nd paragraph in "*2.1. Example Token Binding for Refresh Tokens".* "the" should be removed from "the of PKCS is". Best Regards, Takahiko Kawasaki 2017-03-28 1:32 GMT+09:00 Brian Campbell : > -03 only fixes a few mistakes in and around the examples that I noticed > preparing the slides for the IETF 98 Chicago meeting. > > ---------- Forwarded message ---------- > From: > Date: Mon, Mar 27, 2017 at 11:31 AM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-03.txt > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol of the IETF. > > Title : OAuth 2.0 Token Binding > Authors : Michael B. Jones > John Bradley > Brian Campbell > William Denniss > Filename : draft-ietf-oauth-token-binding-03.txt > Pages : 26 > Date : 2017-03-27 > > Abstract: > This specification enables OAuth 2.0 implementations to apply Token > Binding to Access Tokens, Authorization Codes, and Refresh Tokens. > This cryptographically binds these tokens to a client's Token Binding > key pair, possession of which is proven on the TLS connections over > which the tokens are intended to be used. This use of Token Binding > protects these tokens from man-in-the-middle and token export and > replay attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-token-binding-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-03 > > > 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 > > --94eb2c1b0ede3a66380552af14a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian,

Just a small editorial issu= e on the 4th line in the 2nd paragraph in "2.1. Exampl= e Token Binding for Refresh Tokens".=C2=A0"the" should b= e removed from "the of PKCS is".
Best Regards,

2017-03-28 1:32 GMT+09:0= 0 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">
-03 only fixes a few mistake= s in and around the examples that I noticed preparing the slides for the IE= TF 98 Chicago meeting.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Mar 27, 2017 at 11:31 AM
Subject: [OAUTH-WG] I-D Actio= n: draft-ietf-oauth-token-binding-03.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Token Binding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 William Denniss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-binding-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-27

Abstract:
=C2=A0 =C2=A0This specification enables OAuth 2.0 implementations to apply = Token
=C2=A0 =C2=A0Binding to Access Tokens, Authorization Codes, and Refresh Tok= ens.
=C2=A0 =C2=A0This cryptographically binds these tokens to a client's To= ken Binding
=C2=A0 =C2=A0key pair, possession of which is proven on the TLS connections= over
=C2=A0 =C2=A0which the tokens are intended to be used.=C2=A0 This use of To= ken Binding
=C2=A0 =C2=A0protects these tokens from man-in-the-middle and token export = and
=C2=A0 =C2=A0replay attacks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-oauth-token-binding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-oauth-token-binding-03
https://datatracker.ietf.org/= doc/html/draft-ietf-oauth-token-binding-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u<= wbr>rl2=3Ddraft-ietf-oauth-token-binding-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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


--94eb2c1b0ede3a66380552af14a2-- From nobody Sat Jun 24 06:37:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA2312871F for ; Sat, 24 Jun 2017 06:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVaCXTdNImzI for ; Sat, 24 Jun 2017 06:37:02 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 C870A127735 for ; Sat, 24 Jun 2017 06:37:02 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id f127so31602392pgc.0 for ; Sat, 24 Jun 2017 06:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+/MFeOjt+Hslt4pUsQGG6umSh8+HfHj188AcZtSePZg=; b=DCWXxO9gaCVYxwzZJeP+BxcS1UP/TyOfo/jXUn7xYeN4Cfrki+Yh7+uen8OUq27BBj RpaqXsLKmUWQ+2sYwas5mXMBV85aQJ2JVkuKJzRDFlWyyhEj3stMkliZnx7Z8vnHkC6n 3/IH1TP7TNmb6TVC8sbnvwOGxl8nQy9ybzrrQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+/MFeOjt+Hslt4pUsQGG6umSh8+HfHj188AcZtSePZg=; b=OqQO13SU+Lw7xcGMM6rPtq/c/skkez9yzkS7Knm6dYcIPUVvU5tbzAsId4n8RXCAD2 QXz1QCvmvQNWvcfn6JAr9bB5CIpP+8UHBr3zubYsSshiXWskJ+qT9bp08jY6k2S0jRtH 287fQJcG8tezggy50vRVSXeoqqar4y7K/ho6IXuJ4TMqsVmu3Kt5GtgJmBCeEkTNnwGt 0KeIvyadgKLiYuBWvwSWPoJbNuv6sSyQzyD1fDLRYkE7csarz7HiN76UutITWXzp1tcJ iug4VelcAlMik8nPMkbTxbMwym9q3DoghOCyyYCaM19DgL2jAiWGLs9h1CgppFvn4tjY /K2Q== X-Gm-Message-State: AKS2vOyWpUevfiTZmnwSRK21dzFi7nkIJRGB+IFUoa+5oJH2Qs/KWnxS EtA6XsBLdVRQCJIglOIFFSJ/9ShphzOkDDc4+J/8h0JTb7W92Qd4IN7nzyHZB6rWfSl3oQnhg3+ ZJTjD X-Received: by 10.99.44.206 with SMTP id s197mr13336054pgs.116.1498311422014; Sat, 24 Jun 2017 06:37:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Sat, 24 Jun 2017 06:36:31 -0700 (PDT) In-Reply-To: References: <149063228392.30557.3815696692412964113@ietfa.amsl.com> From: Brian Campbell Date: Sat, 24 Jun 2017 08:36:31 -0500 Message-ID: To: Takahiko Kawasaki Cc: oauth Content-Type: multipart/alternative; boundary="001a1145a2dc12bd800552b4d03a" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-binding-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 13:37:05 -0000 --001a1145a2dc12bd800552b4d03a Content-Type: text/plain; charset="UTF-8" Thanks Takahiko, fixed https://github.com/oauth-token-binding/i-d/commit/f0c61c19e02a54147c3b9280b1f5c41112de35a0 On Sat, Jun 24, 2017 at 1:46 AM, Takahiko Kawasaki wrote: > Dear Brian, > > Just a small editorial issue on the 4th line in the 2nd paragraph in "*2.1. > Example Token Binding for Refresh Tokens".* "the" should be removed from > "the of PKCS is". > > Best Regards, > Takahiko Kawasaki > > > > 2017-03-28 1:32 GMT+09:00 Brian Campbell : > >> -03 only fixes a few mistakes in and around the examples that I noticed >> preparing the slides for the IETF 98 Chicago meeting. >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Mar 27, 2017 at 11:31 AM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-03.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol of the IETF. >> >> Title : OAuth 2.0 Token Binding >> Authors : Michael B. Jones >> John Bradley >> Brian Campbell >> William Denniss >> Filename : draft-ietf-oauth-token-binding-03.txt >> Pages : 26 >> Date : 2017-03-27 >> >> Abstract: >> This specification enables OAuth 2.0 implementations to apply Token >> Binding to Access Tokens, Authorization Codes, and Refresh Tokens. >> This cryptographically binds these tokens to a client's Token Binding >> key pair, possession of which is proven on the TLS connections over >> which the tokens are intended to be used. This use of Token Binding >> protects these tokens from man-in-the-middle and token export and >> replay attacks. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-03 >> >> >> 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 >> >> > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a1145a2dc12bd800552b4d03a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Jun 24, 2017 at 1:46 AM, Takahiko Kawasaki <dar= u.tk@gmail.com> wrote:
Dear Brian,

Just a small editorial issue o<= span style=3D"color:rgb(69,69,69);font-family:'Helvetica Neue';font= -size:12px">n the 4th line in the 2nd paragraph in "2.1. Example To= ken Binding for Refresh Tokens".=C2=A0"the" should be re= moved from "the of PKCS is".

Best Regards,
Ta= kahiko Kawasaki



2017-03-28 1:32 GMT+09:00 Brian Campbell <= ;bcampbell@= pingidentity.com>:
-03 only fixes a few mistakes in and around the examples that I no= ticed preparing the slides for the IETF 98 Chicago meeting.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon= , Mar 27, 2017 at 11:31 AM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oa= uth-token-binding-03.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Token Binding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 William Denniss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-binding-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-27

Abstract:
=C2=A0 =C2=A0This specification enables OAuth 2.0 implementations to apply = Token
=C2=A0 =C2=A0Binding to Access Tokens, Authorization Codes, and Refresh Tok= ens.
=C2=A0 =C2=A0This cryptographically binds these tokens to a client's To= ken Binding
=C2=A0 =C2=A0key pair, possession of which is proven on the TLS connections= over
=C2=A0 =C2=A0which the tokens are intended to be used.=C2=A0 This use of To= ken Binding
=C2=A0 =C2=A0protects these tokens from man-in-the-middle and token export = and
=C2=A0 =C2=A0replay attacks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-oauth-token-binding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-oauth-token-binding-03
https://datatracker.ietf.org/= doc/html/draft-ietf-oauth-token-binding-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u<= wbr>rl2=3Ddraft-ietf-oauth-token-binding-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1145a2dc12bd800552b4d03a-- From nobody Sun Jun 25 22:46:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B332126D05 for ; Sun, 25 Jun 2017 22:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sih8LFfWeseP for ; Sun, 25 Jun 2017 22:46:20 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 6D1C2126B7E for ; Sun, 25 Jun 2017 22:46:20 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j11so13088055ywa.2 for ; Sun, 25 Jun 2017 22:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=PRwMn0nImieO0hxwpecDDmd8KTrcCYeP0l1tXCMC5lk=; b=DQYt4gSYpXGcOomKQKiwQOoJp6jg3YP6KF2Gngx1mbYZSQE4JTgR8482ULfFpQzPf1 0k+C8R9WHfyFRiBtAkeESJ2wRUMu8Zr+CxKBjEV1TVghYpuBFTRpblGC179ITJ58aerU dYzP3iQtOaXy6ugrXJHF0A7IuB5HarspMT3PLI9vrhvQu8bDfLChbU2IWsiUn5H2bHEU UqebA8foH/ZI5A8iJWIhW8wPqG1K3R3b/TBWdrzIeqrx6CmJWAzBafeOV9yH4yltZ+QH mIpNX6IHr0Vwx1gbJYswkJxvVFaEOjkjV0Eo2oahqlA6X6zddSWf90y7LxwtSnYZBT+X 2Khw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=PRwMn0nImieO0hxwpecDDmd8KTrcCYeP0l1tXCMC5lk=; b=sBjy3YBtIYpp5wH6e2YwbJRA8l+HSfzWkLSNeYPmTXPOi+BYFJG6At3EQ7OV0nmFTY JgvH5l0b1RzqgmdIdv+G6u/c5DUkqOmN0lnhgNa2PcN2nBDeMpxrMuRGIChHuSIwC64F OApyK6spyTehhH7ORKcJ+7ZLbk5qpMvpp9BjFgBSxjrUGLZXhJuYf0v36kTziEjrldIi 84CB2175AUycVbUN+DYsEz4pjRZ2AVWPOSzDDsO9ZYACtPendm1yqPlUYnIlG8rkKbG7 59dbBb2J/C9qz0BKByNBdU1zoL0HRkvHu1fqvjJhlIWtU54FcoWMWIWHgIsEdWcPEFV6 Fo2g== X-Gm-Message-State: AKS2vOy5P5cer/XapujDRI7pWZ20Y8G5R1iUnXXxplSeCxSoTFt57w1N /ogVUwBG/X1QXKrR9XiDzkdbLzULR6kq X-Received: by 10.129.169.69 with SMTP id g66mr14020660ywh.205.1498455979463; Sun, 25 Jun 2017 22:46:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.67 with HTTP; Sun, 25 Jun 2017 22:46:19 -0700 (PDT) From: Takahiko Kawasaki Date: Mon, 26 Jun 2017 14:46:19 +0900 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c146d5c5e1b990552d67879" Archived-At: Subject: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 05:46:22 -0000 --94eb2c146d5c5e1b990552d67879 Content-Type: text/plain; charset="UTF-8" Hello, I'm not so sure that this is the right place to ask, but I'm wondering whether it is correct or not that the following non-normative example found in "5. Definitions of Multi-Valued Response Type Combinations " in "OAuth 2.0 Multiple Response Type Encoding Practices " does not include "scope=openid". GET /authorize? response_type=id_token%20token &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &state=af0ifjsldkj HTTP/1.1 Host: server.example.com The reason I'm wondering is that "3.3.2.1. Authentication Request " in "OpenID Connect Core 1.0 " requires Authentication Requests be made as defined in "3.1.2.1. Authentication Request " and "3.1.2.1" requires the scope request parameter contain openid. Best Regards, Takahiko Kawasaki --94eb2c146d5c5e1b990552d67879 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm not so sure that this is= the right place to ask, but I'm wondering whether it is correct or not= that the following non-normative example found in "5.= Definitions of Multi-Valued Response Type Combinations" in "= OAuth 2.0 Multiple Response Type Encoding Practices" does not i= nclude "scope=3D= openid".

  GET /authorize?
    response_type=3Did_token%20token
    &client_id=3Ds6BhdRkqt3
    &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb
    &state=3Daf0ifjsldkj HTTP/1.1
  Host: server.example.com
<= /div>

The reason I'm wondering is that "3.3.2.1. Authentication Request" in "OpenID Connect Core 1.0"= requires Authentication Requests be made as defined in "3.1.2.1. Au= thentication Request" and "3.1.2.1" requires the scope request parameter contain openid.


Best Regards,
Takahiko Kawasaki

--94eb2c146d5c5e1b990552d67879-- From nobody Mon Jun 26 05:16:37 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6149129B39 for ; Mon, 26 Jun 2017 05:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yo9xtHIO08e for ; Mon, 26 Jun 2017 05:16:34 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 3BBA9129B30 for ; Mon, 26 Jun 2017 05:16:34 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id t127so24916834ywc.3 for ; Mon, 26 Jun 2017 05:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kXnNsJBWeeC42dnk4vDAsvyyMQw98AYNbM+vpx3PDGc=; b=bVOKk08uzyrUPcenhltqB/hke30SU+tvr3rK9KMV2xMRBGcERMc9+KowEggcLw5yd/ Imln2S9aUAavLg6PoFxfqA6ak9ykez+Yj3eAJTQpCk+J/Iqmbbvtf3dp0oT348UOawXr Ygo/fqNVmZl5yOdLYBJBVswPGiMhK2Z2trBJ1ZOMHzr4A8gjwkQBpdGd2am9t3YKr/nV aTwyBRx2tA4jE1XRm63OkzpkzQCVgtbfzfq870HhOLRYXx/Y2GnWUa2jsLIvVfbZeWQH dK0cIUSBl8B6MIIqf9Y+d3DudaMt6uKAHNFy6wvorJF/VnJcUwjLc5D4+Ye6fxjCZ6qI Hw/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kXnNsJBWeeC42dnk4vDAsvyyMQw98AYNbM+vpx3PDGc=; b=dBIXJtrgyXMR6xkKw1RYM3sxEVWrgy+sz6be1/Qufbjz4EhqFQ3U+EORqANT5M2lGk wnnFp/SficsqUdbH++KGSbQzLiA8mFnyQqAjf8/7X4WtbP6f2xeWCwopJSoxBDNNbvUn zLTBtZtxnTSgVNKSuP/XwsTnMVkmyst4rH64A/DUwkhyfJISPv7Y2Zz+okevWln3fxii T/vr2mo8KU2b/4iw0M7VTRe1GRRj3YK+XJc3X/54Na4aQFm3Fc2sYselUUaCefG+q4Wo hiKhnneyaZNTmd/BHms2xWJxYWdvMYyOytNFMsxw8cJsLKjfUd/X0VI1HiprquqxPBrt 39EQ== X-Gm-Message-State: AKS2vOwwGIqE2m854tMNILyRQFcBIOF4HoS5xmKcAXSfFN3va0y1dk/l //x3MbZ3nL5lOlfvTMKxOQpRWjGcDQ== X-Received: by 10.129.104.215 with SMTP id d206mr1866461ywc.31.1498479393398; Mon, 26 Jun 2017 05:16:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.67 with HTTP; Mon, 26 Jun 2017 05:16:32 -0700 (PDT) In-Reply-To: References: From: Takahiko Kawasaki Date: Mon, 26 Jun 2017 21:16:32 +0900 Message-ID: To: Philippe Signoret Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a1149018af266b60552dbebca" Archived-At: Subject: Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 12:16:36 -0000 --001a1149018af266b60552dbebca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The response_type of the example includes id_token and it is the reason I've brought it up. id_token triggers Authentication Request. # The response_type in the example in Appendix A does not include id_token and so I've not mentioned it. Best, Taka 2017-06-26 17:09 GMT+09:00 Philippe Signoret < Philippe.Signoret@microsoft.com>: > scope=3Dopenid is required for OpenID Connect Authentication Requests (e.= g. > "3.3.2.1. Authentication Request > " > in "OpenID Connect Core 1.0 > "), > but not for an OAuth 2.0 Authorization Request (e.g. "4.1.1. > Authorization Request = " > in "RFC6749 The OAuth 2.0 Authorization Framework > "). > > > > OpenID Connect is =E2=80=9Can identity layer on top of the OAuth 2.0 prot= ocol=E2=80=9D. > OpenID Connect specs will often refer to aspects of the OAuth 2.0 protoco= l, > but the OAuth 2.0 specs will generally not refer to the OpenID Connect > constructs. (Because OpenID Connect is a specific case of OAuth 2.0.) > > > > Philippe > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Takahiko > Kawasaki > *Sent:* Monday, June 26, 2017 7:46 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type > Encoding Practices > > > > Hello, > > > > I'm not so sure that this is the right place to ask, but I'm wondering > whether it is correct or not that the following non-normative example fou= nd > in "5. Definitions of Multi-Valued Response Type Combinations > " > in "OAuth 2.0 Multiple Response Type Encoding Practices > " > does not include "scope=3Dopenid". > > > > GET /authorize? > > response_type=3Did_token%20token > > &client_id=3Ds6BhdRkqt3 > > &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org %2Fcb > > &state=3Daf0ifjsldkj HTTP/1.1 > > Host: server.example.com > > > > The reason I'm wondering is that "3.3.2.1. Authentication Request > " > in "OpenID Connect Core 1.0 > " > requires Authentication Requests be made as defined in "3.1.2.1. > Authentication Request > " > and "3.1.2.1" requires the scope request parameter contain openid. > > > > > > Best Regards, > > Takahiko Kawasaki > > > --001a1149018af266b60552dbebca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The response_type of the example includes id_token and it is the reason I've brought it up. id_token triggers Authentication Request.

# The response_type in the ex= ample in Appendix A does not include id_token and so I've not mentioned it.
=
Best,
Taka


=

2017-= 06-26 17:09 GMT+09:00 Philippe Signoret <Philippe.Signoret@m= icrosoft.com>:

<= span style=3D"font-size:9.0pt">scope=3Dopenid is required fo= r OpenID Connect Authentication Requests (e.g. "3= .3.2.1. Authentication Request" in "OpenID Connect Core 1.0"), but not for an OAuth 2.0 Authorization Reques= t (e.g. "4.1.1.=C2=A0 Authorization Request" in "RFC6749 The= OAuth 2.0 Authorization Framework").

=C2=A0

OpenID Connect is =E2=80=9Can identity layer on top= of the OAuth 2.0 protocol=E2=80=9D. OpenID Connect specs will often refer = to aspects of the OAuth 2.0 protocol, but the OAuth 2.0 specs will generally not refer to the OpenID Connect constructs. (Because OpenID= Connect is a specific case of OAuth 2.0.)

=C2=A0

Philippe

<= u>=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of Takahiko Kawasaki
Sent: Monday, June 26, 2017 7:46 AM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Enco= ding Practices

=C2=A0

Hello,

=C2=A0

I'm not so sure that this is the right place to = ask, but I'm wondering whether it is correct or not that the following = non-normative example found in "5= . Definitions of Multi-Valued Response Type Combinations" in "= OAuth 2.0 Multiple Response Type Encoding Practices" does not include &= quot;scope=3D= openid".

=C2=A0

=C2=A0 GET /a=
uthorize?
=C2=A0=C2=A0=
=C2=A0 response_type=3Did_token%20token
=C2=A0=C2=A0=
=C2=A0 &client_id=3Ds6BhdRkqt3
=C2=A0=C2=A0=
=C2=A0 &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb
=C2=A0=C2=A0=
=C2=A0 &state=3Daf0ifjsldkj HTTP/1.1
=C2=A0 Host: =
server.example.com

=C2=A0

The reason I'm wondering is that "3.3.2.1. Authentication Request" in "OpenID Connect Core 1.0" requires Authentication Requests be made as def= ined in "3.1.2.1. Authentication Request" and "3.1.2.1" requires the scope request parameter contain openid.

=C2=A0

=C2=A0

Best Regards,

Takahiko Kawasaki

=C2=A0


--001a1149018af266b60552dbebca-- From nobody Mon Jun 26 05:16:53 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA30C129B3F for ; Mon, 26 Jun 2017 05:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUNCd152G878 for ; Mon, 26 Jun 2017 05:16:48 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70ACA129B36 for ; Mon, 26 Jun 2017 05:16:48 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 70so66557821uau.0 for ; Mon, 26 Jun 2017 05:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Y5+Q4PPO/Gzv4s1zDN6UtwuHMf6T7GtoSZZQg/svyl0=; b=jGJOyzONkgHPirEJGTnlfE4FNHa2oTvofVtMbE8L5KV3oqxLlASJQjtmwJeV70UGWh x7JG7uqSVduDznJkhm4J0SOww7CQdOIfJKWmP+TwyQnuqGvQl7iw4wpQw7YRrVzmpviC DOJRPsKZmgsCtxM8XhrG6x+CEC00DDsSyvUp4+OBMVcUoxQLlurHu6AxZ49XvvxfCO/R c0TRIKGHAB2vtdNbALbbhEfp3KIBKP391Tea4QFZYLCQMWLjwb2zNAwrXxCAwklXzlvZ Sa3DxCDXXSy/vfuhFNa1n/1ZLbxtWF2Yy10eWrOGZ8lEAUC9OMqUrdpglHF1WYgnoanZ LXPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Y5+Q4PPO/Gzv4s1zDN6UtwuHMf6T7GtoSZZQg/svyl0=; b=uNSqYfkPXU9tmi7C4jJub2pU22gowkLb8ozoIDlTCdM5U+Ow9QWJc8AWDcGWh3ahaO VtFjc/FicojsmNqtGMMJdwsT3aJoWpxve0RB6IF0xwfGKTfRNB40AMOWiS0uk7V2MI+7 AOKKvW7hk2YQauJEm1bnOv8KT+yVGItwPL8f3VxyS+WtvY/tcb9EfZh+WcJ5yiWcXVq3 p6tjlsJ2u8TAk93jMLqLxLe4bhtQMAO3Lk8P8/ZSuDrH3pYKbrXIo5sScggGMBSNRgRd c9SuSLug2rJEjzx+SWCrUQI5iUc+4ctOQxzRyBMW5/lozetvL0ME+KUQmeyUWhbVk0h+ m2+g== X-Gm-Message-State: AKS2vOw/wOK7klkkWRlPzXLuJNtag7eldEkG94LMLsWWTqYy17QIeEpY TSWVuhfzP1tGjn3Ob95Ij5TeiiAc7Q== X-Received: by 10.176.7.105 with SMTP id h96mr13949330uah.134.1498479407376; Mon, 26 Jun 2017 05:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Mon, 26 Jun 2017 05:16:47 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Mon, 26 Jun 2017 08:16:47 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c124316c7abf30552dbec62" Archived-At: Subject: [OAUTH-WG] Agenda requests for Prague X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 12:16:52 -0000 --94eb2c124316c7abf30552dbec62 Content-Type: text/plain; charset="UTF-8" All, If you have not done so already, please send us your agenda requests for the coming meeting in Prague. Regards, Rifaat & Hannes --94eb2c124316c7abf30552dbec62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

If you have not done so already, p= lease send us your agenda requests for the coming meeting in Prague.
<= div>
Regards,
=C2=A0Rifaat & Hannes
--94eb2c124316c7abf30552dbec62-- From nobody Mon Jun 26 05:40:44 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C9B129B4D for ; Mon, 26 Jun 2017 05:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImKjLyQWjo4x for ; Mon, 26 Jun 2017 05:40:41 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC01129B4C for ; Mon, 26 Jun 2017 05:40:41 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id j53so61701uaa.2 for ; Mon, 26 Jun 2017 05:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KH1iX/zdm+7LyHzsirvxBb3At1KMAPnGEC3bVDfQRt4=; b=AEFryp4u6qSCPzCV0cq5qg2+QPVoz2VFKjZGf6hSYxGg1HE8FgxyXKcriJdRZXFwhM FjLmxtdzQtCSZML4t7ED52vkupu6vSzSmb1dGGdjt6C0pQuQAokzhV0SWnIJUoDNGq/d sXE3EcFclBeIVAUkhUKvZ2mq1Z0FwvpZxnT/LIT5LHyW67EhQueLpICN6gjRA7tFdzQy SfMwKUOcdXDJ5vRrEvTSTToEDQjneuTM7F4xFLHlfOsqw03Thyiq96OLrLPggOuTXD9I M9af5J7lEwiq/sPhzu9IC/MNqGEGk2D26EUTcfx/WWzMEm1v5bBdvtjBwUtSytoPhZ18 qNXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KH1iX/zdm+7LyHzsirvxBb3At1KMAPnGEC3bVDfQRt4=; b=GCd5CTG2YkEs6fCBc47GWVeBAyA8p7FBr5tAt++1ysG3CUakxv16i62xksyy4RyznF OXOAjc0DZ2VRMZr9oD/guxpD/BX/IjY5jR0HXStMjd2iYtsibi8VSBCEti4/Xp39jEad 379Kqryp6Jc/BzV8Er7auDFsls8RBe9tp+kWjWpvXb/tNl4Kpp1JDrLH7CeFixk3wqbQ LwMhWGZblv/S9Dr5RBi3FNctrT7vwHCcx2PQtYvQclP6102TioBovT33JvGON8BhXcsD 9IEedLzCPLZX/IeEp65dlmqJBvOfoFlcnotv+TXQsLtSyY0ej/hxgd9+1obcu9LXl044 ApmQ== X-Gm-Message-State: AKS2vOxrplkKe9C6OM93F2NJvw73JwLANBYA3qJzaNZ27XHgvH75rZ9M D12WgKLPErBhpTIpD0GO3Zf/y4F7sX3n X-Received: by 10.159.36.5 with SMTP id 5mr13367931uaq.19.1498480840369; Mon, 26 Jun 2017 05:40:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Mon, 26 Jun 2017 05:40:39 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Mon, 26 Jun 2017 08:40:39 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a113cfb963171af0552dc4292" Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 12:40:43 -0000 --001a113cfb963171af0552dc4292 Content-Type: text/plain; charset="UTF-8" Hi (as individual), I have reviewed this version of the document and I have the following comments/questions: Section 2.1, page 8, last paragraph: "In the absence of one-time-use or other semantics specific to the token type, the act of performing a token exchange has no impact on the validity of the subject token or actor token." Would the validity of the new issued token be impacted later on by the validity of the subject or actor tokens? Section 2.2.2, page 10, second paragraph: "If the authorization server is unwilling or unable to issue a token for all the target services indicated by the "resource" or "audience" parameters, the "invalid_target" error code MAY be used in the error response." Can you please elaborate on why the above text is using "MAY" for the use of "invalid_target" in this case? Section 4.1, page 14, second paragraph: "However, claims within the "act" claim pertain only to the identity of the actor and are not relevant to the validity of the containing JWT in the same manner as the top-level claims. Consequently, claims such as "exp", "nbf", and "aud" are not meaningful when used within an "act" claim, and therefore should not be used." If the "exp", "nbf", and "aud" claims are not meaningful inside the "act" claim, why is the sentence stating that it "should not be used"? Would it not be more appropriate to state that it "must not be used" instead? Regards, Rifaat On Fri, Jun 2, 2017 at 3:05 PM, Rifaat Shekh-Yusef wrote: > All, > > We are starting a WGLC on the Token Exchange document: > https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 > > Please, review the document and provide feedback on any issues you see > with the document. > > The WGLC will end in two weeks, on June 17, 2017. > > Regards, > Rifaat and Hannes > > --001a113cfb963171af0552dc4292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi (as individual),

I have r= eviewed this version of the document and I have the following comments/ques= tions:


Section 2.1, page 8, last pa= ragraph:

=C2=A0 =C2=A0"In the absence of one-= time-use or other semantics specific to the
=C2=A0 =C2=A0 token t= ype, the act of performing a token exchange has no impact on
=C2= =A0 =C2=A0 the validity of the subject token or actor token."

Would the validity of the new issued token be impacted lat= er on by the validity of the subject or actor tokens?

<= div>

Section 2.2.2, page 10, second paragraph:=

=C2=A0 "If the authorization server is unwil= ling or unable to issue a token
=C2=A0 =C2=A0for all the target s= ervices indicated by the "resource" or "audience"
=
=C2=A0 =C2=A0parameters, the "invalid_target" error code MAY= be used in the error
=C2=A0 =C2=A0response."

=
Can you please elaborate on why the above text is using "MA= Y" for the use of "invalid_target" in this case?
<= br>


Section 4.1, page 14, second pa= ragraph:

=C2=A0 "However, claims within the &= quot;act" claim pertain only to the identity
=C2=A0 =C2=A0of= the actor and are not relevant to the validity of the containing
=C2=A0 =C2=A0JWT in the same manner as the top-level claims.=C2=A0 Consequ= ently, claims
=C2=A0 =C2=A0such as "exp", "nbf&quo= t;, and "aud" are not meaningful when used within
=C2= =A0 =C2=A0an "act" claim, and therefore should not be used."=

If the "exp", "nbf", and &quo= t;aud" claims are not meaningful inside the "act"
= claim, why is the sentence stating that it "should not be used"?<= /div>
Would it not be more appropriate to state that it "must not = be used" instead?

Regards,
=C2=A0Ri= faat





On Fri, Jun 2, 2= 017 at 3:05 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

We are starting a WGLC on the Token Exchange document:=

Please, review the document and = provide feedback on any issues you see with the document.

The WGLC will end in two weeks, on June 17, 2017.

Regards,
=C2=A0Rifaat and Hannes


--001a113cfb963171af0552dc4292-- From nobody Mon Jun 26 10:59:29 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E08712EB25 for ; Mon, 26 Jun 2017 10:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMku3z1Q15Vj for ; Mon, 26 Jun 2017 10:59:26 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::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 CC82112EB24 for ; Mon, 26 Jun 2017 10:59:25 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id b81so2730403yba.2 for ; Mon, 26 Jun 2017 10:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=op3OvKvr48MZYTstPzIO9EMDEIZlaj/l7smueClNVto=; b=DZPuob8CsSXEAMZdrFhOEFRD8JvBUZ82HYWAiAV7ConFHSvkvklw5mF75XqreRzsnq PNuZOqYHDQWFcsdAm7mZdf0CzyQEKtsWhyP0MPYEYWqU2/fiZS7V3oFqepBdl7a7Lu9v 6r/BcKun+Dk+64c435CqD9bURUCfY66EqfaqVduJY0YeCp0ykHyAhFDhi7pOBYfJHEuQ 6e8g0mQ4hI4FXKX5bOA3NIVjb9cEEAmIB2Cj6L9mvad7j7mUdDcvM5kBEhajvcxLU7/x 0/w9tIkm9xZk6dT51vlYO8YljFzkHDnGDCWmMF1odltjo04JnMcTN4zPLXdBIv4Pbaod /YKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=op3OvKvr48MZYTstPzIO9EMDEIZlaj/l7smueClNVto=; b=XlZzgT78t52rqid+YzNSVJdgIQYnSeM5pCbNxvyJSEeKVXIlQqEFX6nK9+lAhqASZq cdDEzvyaHXaefTXj2w9wvtzCatDAHVePz1XH+jPvsJxYomN1mLKk8ZREioS9+pxQwzFU qGlm/VmzDb07U/f+WgMFrX/eL9e41jHiWjzVO07B7ae1jdnsKcTr/a55KImeh4ABpqig rCcSaOe9GrlIZ+OL79y+nt6OtC0W9upzhVj4yMzFCmTsu8o4XofUH1u97xjnOmBAAphQ DPmL/UGGWrIV4XG9LYu80bGJysSkbo5g6FhIZYciqBXfDQxa7ISFlxR+XiAvGlY25Vcf Wpfg== X-Gm-Message-State: AKS2vOwjN19EsryuO/TQgRyl7s0IgiGu0XpgtpTkie5tO5gmYpGxMu1V o/sw4Pkkf7lHc/kojFpcAjFUGAbo8A== X-Received: by 10.37.204.138 with SMTP id l132mr1026244ybf.176.1498499964837; Mon, 26 Jun 2017 10:59:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.67 with HTTP; Mon, 26 Jun 2017 10:59:24 -0700 (PDT) In-Reply-To: References: From: Takahiko Kawasaki Date: Tue, 27 Jun 2017 02:59:24 +0900 Message-ID: To: Philippe Signoret Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c075b3219a5610552e0b671" Archived-At: Subject: Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:59:29 -0000 --94eb2c075b3219a5610552e0b671 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you. Please let me ask a simplified question. If an authorization server returns this response (including id_token): HTTP/1.1 302 Found Location: https://client.example.org/cb# access_token=3DSlAV32hkKG &token_type=3Dbearer &id_token=3DeyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso &expires_in=3D3600 &state=3Daf0ifjsldkj when it receives this request (without scope=3Dopenid): GET /authorize? response_type=3Did_token%20token &client_id=3Ds6BhdRkqt3 &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb &state=3Daf0ifjsldkj HTTP/1.1 Host: server.example.com , is the implementation of the authorization server correct? Best Regards, Takahiko Kawasaki 2017-06-26 21:53 GMT+09:00 Philippe Signoret < Philippe.Signoret@microsoft.com>: > None of the examples in that spec are _*OpenID Connect*_ authentication > requests. They are, however, valid _*OAuth 2.0**_* authorization > requests. The one in question demonstrates use of the > response_mode=3Did_token, as defined in the realm of OAuth 2.0. If (and o= nly > if) it had scope=3Dopenid, _*then*_ it would become an OpenID Connect aut= h > request, and the OpenID Connect specs would apply. > > > > In other words, the fact that id_token is in the response_type does _*not= **_ > *automatically make it an OpenID Connect request. > > > > Another way of seeing it is that the OAuth 2.0 Multiple Response Type > Encoding spec is laying some foundations, as part of the OAuth 2.0 > framework, upon which OpenID Connect is then built. > > > > In Section 11.3. OAuth Authorization Endpoint Response Types Registry > , the OAuth 2.0 spec > (RFC 6749) defines a registry of response types: > > > > This specification establishes the OAuth Authorization Endpoint > > Response Types registry. > > > > Then, in Section 3, ID Token Response Type > , > OAuth 2.0 Multiple Response Types registers =E2=80=9Cid_token=E2=80=9D as= a response type > in that same registry: > > > > This section registers a new Response Type, the id_token, in accordance > with the stipulations in the OAuth 2.0 specification, Section 8.4. The > intended purpose of the id_token is that it MUST provide an assertion of > the identity of the Resource Owner as understood by the Authorization > Server. The assertion MUST specify a targeted audience, e.g. the requesti= ng > Client. However, the specific semantics of the assertion and how it can b= e > validated are not specified in this document. > > > > Finally, on that OAuth 2.0 foundation, the OpenID Connect spec defines > (amongst other things) that including =E2=80=9Cscope=3Dopenid=E2=80=9D is= how the client > indicates that this is an OpenID Connect request, makes use of the > previously registered Response Type =E2=80=9Cid_token=E2=80=9D (in some f= lows=E2=80=94other flows > don=E2=80=99t use the =E2=80=9Cid_token=E2=80=9D response type), and proc= eeds to specify the format > and contents of the ID Token: > > > > OpenID Connect implements authentication as an extension to the OAuth 2.0 > authorization process. Use of this extension is requested by Clients by > including the openid scope value in the Authorization Request. > Information about the authentication performed is returned in a *JSON Web > Token (JWT)* [= JWT] > called an ID Token (see *Section 2* > ). > > > > Philippe > > > > *From:* Takahiko Kawasaki [mailto:daru.tk@gmail.com] > *Sent:* Monday, June 26, 2017 2:17 PM > *To:* Philippe Signoret > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type > Encoding Practices > > > > The response_type of the example includes id_token and it is the reason > I've brought it up. id_token triggers Authentication Request. > > > > # The response_type in the example in Appendix A > > does not include id_token and so I've not mentioned it. > > > > Best, > > Taka > > > > > > > > 2017-06-26 17:09 GMT+09:00 Philippe Signoret com>: > > scope=3Dopenid is required for OpenID Connect Authentication Requests (e.= g. > "3.3.2.1. Authentication Request > " > in "OpenID Connect Core 1.0 > "), > but not for an OAuth 2.0 Authorization Request (e.g. "4.1.1. > Authorization Request > " > in "RFC6749 The OAuth 2.0 Authorization Framework > > "). > > > > OpenID Connect is =E2=80=9Can identity layer on top of the OAuth 2.0 prot= ocol=E2=80=9D. > OpenID Connect specs will often refer to aspects of the OAuth 2.0 protoco= l, > but the OAuth 2.0 specs will generally not refer to the OpenID Connect > constructs. (Because OpenID Connect is a specific case of OAuth 2.0.) > > > > Philippe > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Takahiko > Kawasaki > *Sent:* Monday, June 26, 2017 7:46 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type > Encoding Practices > > > > Hello, > > > > I'm not so sure that this is the right place to ask, but I'm wondering > whether it is correct or not that the following non-normative example fou= nd > in "5. Definitions of Multi-Valued Response Type Combinations > " > in "OAuth 2.0 Multiple Response Type Encoding Practices > " > does not include "scope=3Dopenid". > > > > GET /authorize? > > response_type=3Did_token%20token > > &client_id=3Ds6BhdRkqt3 > > &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org %2Fcb > > &state=3Daf0ifjsldkj HTTP/1.1 > > Host: server.example.com > > > > The reason I'm wondering is that "3.3.2.1. Authentication Request > " > in "OpenID Connect Core 1.0 > " > requires Authentication Requests be made as defined in "3.1.2.1. > Authentication Request > " > and "3.1.2.1" requires the scope request parameter contain openid. > > > > > > Best Regards, > > Takahiko Kawasaki > > > > > --94eb2c075b3219a5610552e0b671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you. Please let me ask a simplified question.
If an authorization server returns this response (including id_token):
  HTTP/1.1 302 Fo=
und
  Location: https://client.examp=
le.org/cb#
  access_token=3DSlAV32hkKG
  &token_type=3Dbearer
  &id_token=3DeyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3D3600
  &state=3Daf0ifjsldkj
when it receives this req= uest (without scope=3Dopenid):
  GET /auth=
orize?
    response_type=3Did_token%20token
    &client_id=3Ds6BhdRkqt3
    &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb
    &state=3Daf0ifjsldkj HTTP/1.1
  Host: server.example.com
<= /div>
, is the implementation of the authorization server correct?

Best Regards,
Takahiko Kawasaki

201= 7-06-26 21:53 GMT+09:00 Philippe Signoret <Philippe.Signoret= @microsoft.com>:

None of the examples in that spec are _OpenID Co= nnect_ authentication requests. They are, however, valid _OAuth 2.0<= /i>_ authorization requests. The one in question demonstrates use of the response_mode=3Did_token, as defined in t= he realm of OAuth 2.0. If (and only if) it had scope=3Dopenid, _then= _ it would become an OpenID Connect auth request, and the OpenID Connect sp= ecs would apply.

=C2=A0

In other words, the fact that id_token is in the re= sponse_type does _not_ automatically make it an OpenID Connect request.

=C2=A0

Another way of seeing it is that the OAuth 2.0 Mult= iple Response Type Encoding spec is laying some foundations, as part of the= OAuth 2.0 framework, upon which OpenID Connect is then built.

=C2=A0

In Section 11.3. OAuth Authorization Endpoint Response Types Registry,= the OAuth 2.0 spec (RFC 6749) defines a registry of response types:=

=C2=A0

=C2=A0=C2=A0 This specification establishes the OAuth Authorizat= ion Endpoint

=C2=A0=C2=A0 Response Types registry.

=C2=A0

Then, in Section 3, ID Token Response Type, OAuth 2.0 Multiple Response Types re= gisters =E2=80=9Cid_token=E2=80=9D as a response type in that same registry= :

=C2=A0

This section registers a new Re= sponse Type, the=C2=A0id_token, in accordance with the stipulations in the OAuth 2.0 specification, Sectio= n 8.4. The intended purpose of the=C2=A0= id_token=C2=A0is that it MUST provide an assertion of the identity of the Resource Owner as= understood by the Authorization Server. The assertion MUST specify a targe= ted audience, e.g. the requesting Client. However, the specific semantics o= f the assertion and how it can be validated are not specified in this document.

=C2=A0

Finally, on that OAuth 2.0 foundation, the OpenID C= onnect spec defines (amongst other things) that including =E2=80=9Cscope=3D= openid=E2=80=9D is how the client indicates that this is an OpenID Connect request, makes use of the previously registered Response Type =E2= =80=9Cid_token=E2=80=9D (in some flows=E2=80=94other flows don=E2=80=99t us= e the =E2=80=9Cid_token=E2=80=9D response type), and proceeds to specify th= e format and contents of the ID Token:

=C2=A0

OpenID Connect implements authe= ntication as an extension to the OAuth 2.0 authorization process. Use of th= is extension is requested by Clients by including the=C2=A0openid=C2=A0<= /span>scope value in the Authorization Request. Information about the authentication p= erformed is returned in a=C2=A0JSON Web Token (JWT)=C2=A0[JWT] called an ID Token (see=C2=A0= Section=C2=A02).

=C2=A0

Philippe

<= u>=C2=A0

From: Takahiko Kawasaki [mailto:daru.tk@gmail.com]
Sent: Monday, June 26, 2017 2:17 PM
To: Philippe Signoret <Philippe.Signoret@microsoft.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type = Encoding Practices

=C2=A0

The response_type of the example includes id_token and it = is the reason I've brought it up. id_token trigger= s Authentication Request.

=C2=A0

# The response_type in the example in Appendix A does not include id_token and so I've not mentioned it.

=C2=A0

Best,

Taka

=C2=A0

=C2=A0

=C2=A0

2017-06-26 17:09 GMT+09:00 Philippe Signoret <Philippe.= Signoret@microsoft.com>:

scope=3Dopenid is required for OpenID Connect Authentication Requests (e.g. "3.3.2.1. Authentication Request" in "OpenID Connect Core 1.0"), but not for an OAuth 2.0 Authorization Reques= t (e.g. "4.1.1.=C2=A0 Authorization Request" in "RFC6749 The OAuth 2.0 Authorization Framework").

=C2=A0

OpenID Connect is =E2=80=9Can identity layer on top= of the OAuth 2.0 protocol=E2=80=9D. OpenID Connect specs will often refer = to aspects of the OAuth 2.0 protocol, but the OAuth 2.0 specs will generally = not refer to the OpenID Connect constructs. (Because OpenID Connect is a sp= ecific case of OAuth 2.0.)

=C2=A0

Philippe

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of Takahiko Kawasaki
Sent: Monday, June 26, 2017 7:46 AM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Enco= ding Practices

=C2=A0

Hello,

=C2=A0

I'm not so sure that this is the right place to = ask, but I'm wondering whether it is correct or not that the following = non-normative example found in "5= . Definitions of Multi-Valued Response Type Combinations" in "= OAuth 2.0 Multiple Response Type Encoding Practices" does not include &= quot;scope=3D= openid".

=C2=A0

=C2=A0 GET /a=
uthorize?
=C2=A0=C2=A0=
=C2=A0 response_type=3Did_token%20token
=C2=A0=C2=A0=
=C2=A0 &client_id=3Ds6BhdRkqt3
=C2=A0=C2=A0=
=C2=A0 &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb
=C2=A0=C2=A0=
=C2=A0 &state=3Daf0ifjsldkj HTTP/1.1
=C2=A0 Host: =
server.example.com

=C2=A0

The reason I'm wondering is that "3.3.2.1. Authentication Request" in "OpenID Connect Core 1.0" requires Authentication Requests be made as def= ined in "3.1.2.1. Authentication Request" and "3.1.2.1" requires the scope request parameter contain openid.

=C2=A0

=C2=A0

Best Regards,

Takahiko Kawasaki

=C2=A0

=C2=A0


--94eb2c075b3219a5610552e0b671-- From nobody Mon Jun 26 13:40:31 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38E212EB5F for ; Mon, 26 Jun 2017 13:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.392 X-Spam-Level: X-Spam-Status: No, score=0.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mx.aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voBXhxjgsCcU for ; Mon, 26 Jun 2017 13:40:27 -0700 (PDT) Received: from omr-a020e.mx.aol.com (omr-a020e.mx.aol.com [204.29.186.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED85112EB5E for ; Mon, 26 Jun 2017 13:40:26 -0700 (PDT) Received: from mtaout-mac01.mx.aol.com (mtaout-mac01.mx.aol.com [172.26.222.205]) by omr-a020e.mx.aol.com (Outbound Mail Relay) with ESMTP id 126C03800095; Mon, 26 Jun 2017 16:40:26 -0400 (EDT) Received: from [10.182.32.79] (unknown [10.182.32.79]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 8754538000083; Mon, 26 Jun 2017 16:40:25 -0400 (EDT) To: Takahiko Kawasaki , Philippe Signoret References: Cc: "oauth@ietf.org" From: George Fletcher Organization: AOL LLC Message-ID: <506d0030-68af-468b-7b2a-2d8c6d758ce4@aol.com> Date: Mon, 26 Jun 2017 16:42:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1B55F11A14A052F1198387D2" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1498509626; bh=5OBYJb9lyh8OgvbG9/0okjcYcK4jqdR0ZaixHzTykcc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=G3X2VBAr/XZA2Zr2KMwsLQZPWWFUIYzELr2dToWFgRBD7S9emYV8mT3U/Vu7h+STU IBF2HPVjpRyR4OSKTGitEiL1yxyVTdKahwU9HNB1VwjnHz4S1/fP/YWKfqzAOMrzpp oM2u6e3hsC7t2m18d1X/trx4fpkO/dajK/o7Xcwg= x-aol-sid: 3039ac1adecd595171394154 X-AOL-IP: 10.182.32.79 Archived-At: Subject: Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 20:40:30 -0000 This is a multi-part message in MIME format. --------------1B55F11A14A052F1198387D2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit From section 3.1.2.1 of the OpenID Connect Core... scope REQUIRED. OpenID Connect requests MUST contain theopenidscope value. *If the****openid****scope value is not present, the behavior is entirely unspecified.* Other scope values MAY be present. Scope values used that are not understood by an implementation SHOULD be ignored. See Sections5.4 and11 for additional scope values defined by this specification. In this light, there is no specification that covers the behavior of the AS given the authorization request you provided. At least that is my reading of the specs. Thanks, George On 6/26/17 1:59 PM, Takahiko Kawasaki wrote: > Thank you. Please let me ask a simplified question. > > If an authorization server returns this response (including id_token): > HTTP/1.1 302 Found Location: https://client.example.org/cb# > access_token=SlAV32hkKG &token_type=bearer &id_token=eyJ0 ... > NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso &expires_in=3600 > &state=af0ifjsldkj > when it receives this request (without scope=openid): > GET /authorize? > response_type=id_token%20token > &client_id=s6BhdRkqt3 > &redirect_uri=https%3A%2F%2Fclient.example.org %2Fcb > &state=af0ifjsldkj HTTP/1.1 > Host:server.example.com > , is the implementation of the authorization server correct? > > Best Regards, > Takahiko Kawasaki > > > 2017-06-26 21:53 GMT+09:00 Philippe Signoret > >: > > None of the examples in that spec are _/OpenID Connect/_ > authentication requests. They are, however, valid _/OAuth 2.0//_/ > authorization requests. The one in question demonstrates use of > the response_mode=id_token, as defined in the realm of OAuth 2.0. > If (and only if) it had scope=openid, _/then/_ it would become an > OpenID Connect auth request, and the OpenID Connect specs would > apply. > > In other words, the fact that id_token is in the response_type > does _/not//_ /automatically make it an OpenID Connect request. > > Another way of seeing it is that the OAuth 2.0 Multiple Response > Type Encoding spec is laying some foundations, as part of the > OAuth 2.0 framework, upon which OpenID Connect is then built. > > In Section 11.3. OAuth Authorization Endpoint Response Types > Registry , the > OAuth 2.0 spec (RFC 6749) defines a registry of response types: > > This specification establishes the OAuth Authorization Endpoint > > Response Types registry. > > Then, in Section 3, ID Token Response Type > , > OAuth 2.0 Multiple Response Types registers “id_token” as a > response type in that same registry: > > This section registers a new Response Type, theid_token, in > accordance with the stipulations in the OAuth 2.0 specification, > Section 8.4. The intended purpose of theid_tokenis that it MUST > provide an assertion of the identity of the Resource Owner as > understood by the Authorization Server. The assertion MUST specify > a targeted audience, e.g. the requesting Client. However, the > specific semantics of the assertion and how it can be validated > are not specified in this document. > > Finally, on that OAuth 2.0 foundation, the OpenID Connect spec > defines (amongst other things) that including “scope=openid” is > how the client indicates that this is an OpenID Connect request, > makes use of the previously registered Response Type “id_token” > (in some flows—other flows don’t use the “id_token” response > type), and proceeds to specify the format and contents of the ID > Token: > > OpenID Connect implements authentication as an extension to the > OAuth 2.0 authorization process. Use of this extension is > requested by Clients by including theopenidscope value in the > Authorization Request. Information about the authentication > performed is returned in a*JSON Web Token (JWT)* > [JWT] > called an ID Token (see*Section 2* > ). > > Philippe > > *From:*Takahiko Kawasaki [mailto:daru.tk@gmail.com > ] > *Sent:* Monday, June 26, 2017 2:17 PM > *To:* Philippe Signoret > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response > Type Encoding Practices > > The response_type of the example includes id_token and it is the > reason I've brought it up. id_token triggers Authentication Request. > > # The response_type in the example in Appendix A > > does not include id_token and so I've not mentioned it. > > Best, > > Taka > > 2017-06-26 17:09 GMT+09:00 Philippe Signoret > >: > > scope=openidis required for OpenID Connect Authentication > Requests (e.g. "3.3.2.1. Authentication Request > " > in "OpenID Connect Core 1.0 > "), > but not for an OAuth 2.0 Authorization Request (e.g. "4.1.1. > Authorization Request > " > in "RFC6749 The OAuth 2.0 Authorization Framework > "). > > OpenID Connect is “an identity layer on top of the OAuth 2.0 > protocol”. OpenID Connect specs will often refer to aspects of > the OAuth 2.0 protocol, but the OAuth 2.0 specs will generally > not refer to the OpenID Connect constructs. (Because OpenID > Connect is a specific case of OAuth 2.0.) > > Philippe > > *From:*OAuth [mailto:oauth-bounces@ietf.org > ] *On Behalf Of *Takahiko Kawasaki > *Sent:* Monday, June 26, 2017 7:46 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Example in OAuth 2.0 Multiple Response > Type Encoding Practices > > Hello, > > I'm not so sure that this is the right place to ask, but I'm > wondering whether it is correct or not that the following > non-normative example found in "5. Definitions of Multi-Valued > Response Type Combinations > " > in "OAuth 2.0 Multiple Response Type Encoding Practices > " > does not include "scope=openid". > > GET /authorize? > > response_type=id_token%20token > > &client_id=s6BhdRkqt3 > > &redirect_uri=https%3A%2F%2Fclient.example.org > %2Fcb > > &state=af0ifjsldkj HTTP/1.1 > > Host: server.example.com > > > The reason I'm wondering is that "3.3.2.1. Authentication > Request > " > in "OpenID Connect Core 1.0 > " > requires Authentication Requests be made as defined in > "3.1.2.1. Authentication Request > " > and "3.1.2.1" requires the scope request parameter contain openid. > > Best Regards, > > Takahiko Kawasaki > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------1B55F11A14A052F1198387D2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit From section 3.1.2.1 of the OpenID Connect Core...

scope
REQUIRED. OpenID Connect requests MUST contain the openid scope value. If the openid scope value is not present, the behavior is entirely unspecified. Other scope values MAY be present. Scope values used that are not understood by an implementation SHOULD be ignored. See Sections 5.4 and 11 for additional scope values defined by this specification.

In this light, there is no specification that covers the behavior of the AS given the authorization request you provided.


At least that is my reading of the specs.

Thanks,
George

On 6/26/17 1:59 PM, Takahiko Kawasaki wrote:
Thank you. Please let me ask a simplified question.

If an authorization server returns this response (including id_token):
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
  access_token=SlAV32hkKG
  &token_type=bearer
  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3600
  &state=af0ifjsldkj
when it receives this request (without scope=openid):
  GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com
, is the implementation of the authorization server correct?

Best Regards,
Takahiko Kawasaki


2017-06-26 21:53 GMT+09:00 Philippe Signoret <Philippe.Signoret@microsoft.com>:

None of the examples in that spec are _OpenID Connect_ authentication requests. They are, however, valid _OAuth 2.0_ authorization requests. The one in question demonstrates use of the response_mode=id_token, as defined in the realm of OAuth 2.0. If (and only if) it had scope=openid, _then_ it would become an OpenID Connect auth request, and the OpenID Connect specs would apply.

 

In other words, the fact that id_token is in the response_type does _not_ automatically make it an OpenID Connect request.

 

Another way of seeing it is that the OAuth 2.0 Multiple Response Type Encoding spec is laying some foundations, as part of the OAuth 2.0 framework, upon which OpenID Connect is then built.

 

In Section 11.3. OAuth Authorization Endpoint Response Types Registry, the OAuth 2.0 spec (RFC 6749) defines a registry of response types:

 

   This specification establishes the OAuth Authorization Endpoint

   Response Types registry.

 

Then, in Section 3, ID Token Response Type, OAuth 2.0 Multiple Response Types registers “id_token” as a response type in that same registry:

 

This section registers a new Response Type, the id_token, in accordance with the stipulations in the OAuth 2.0 specification, Section 8.4. The intended purpose of the id_token is that it MUST provide an assertion of the identity of the Resource Owner as understood by the Authorization Server. The assertion MUST specify a targeted audience, e.g. the requesting Client. However, the specific semantics of the assertion and how it can be validated are not specified in this document.

 

Finally, on that OAuth 2.0 foundation, the OpenID Connect spec defines (amongst other things) that including “scope=openid” is how the client indicates that this is an OpenID Connect request, makes use of the previously registered Response Type “id_token” (in some flows—other flows don’t use the “id_token” response type), and proceeds to specify the format and contents of the ID Token:

 

OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. Use of this extension is requested by Clients by including the openid scope value in the Authorization Request. Information about the authentication performed is returned in a JSON Web Token (JWT) [JWT] called an ID Token (see Section 2).

 

Philippe

 

From: Takahiko Kawasaki [mailto:daru.tk@gmail.com]
Sent: Monday, June 26, 2017 2:17 PM
To: Philippe Signoret <Philippe.Signoret@microsoft.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

 

The response_type of the example includes id_token and it is the reason I've brought it up. id_token triggers Authentication Request.

 

# The response_type in the example in Appendix A does not include id_token and so I've not mentioned it.

 

Best,

Taka

 

 

 

2017-06-26 17:09 GMT+09:00 Philippe Signoret <Philippe.Signoret@microsoft.com>:

scope=openid is required for OpenID Connect Authentication Requests (e.g. "3.3.2.1. Authentication Request" in "OpenID Connect Core 1.0"), but not for an OAuth 2.0 Authorization Request (e.g. "4.1.1.  Authorization Request" in "RFC6749 The OAuth 2.0 Authorization Framework").

 

OpenID Connect is “an identity layer on top of the OAuth 2.0 protocol”. OpenID Connect specs will often refer to aspects of the OAuth 2.0 protocol, but the OAuth 2.0 specs will generally not refer to the OpenID Connect constructs. (Because OpenID Connect is a specific case of OAuth 2.0.)

 

Philippe

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Takahiko Kawasaki
Sent: Monday, June 26, 2017 7:46 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

 

Hello,

 

I'm not so sure that this is the right place to ask, but I'm wondering whether it is correct or not that the following non-normative example found in "5. Definitions of Multi-Valued Response Type Combinations" in "OAuth 2.0 Multiple Response Type Encoding Practices" does not include "scope=openid".

 

  GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

 

The reason I'm wondering is that "3.3.2.1. Authentication Request" in "OpenID Connect Core 1.0" requires Authentication Requests be made as defined in "3.1.2.1. Authentication Request" and "3.1.2.1" requires the scope request parameter contain openid.

 

 

Best Regards,

Takahiko Kawasaki

 

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------1B55F11A14A052F1198387D2-- From nobody Mon Jun 26 21:20:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70509128CFF for ; Mon, 26 Jun 2017 21:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoL8zxwXntlr for ; Mon, 26 Jun 2017 21:20:29 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90AB5128CF0 for ; Mon, 26 Jun 2017 21:20:28 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id s9so6009058ybe.3 for ; Mon, 26 Jun 2017 21:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JbRTMv5FB29QfaOqHuCFoP8eqbdWycZVharsUHUzx7s=; b=CSWX2y1mfAqNWbK09r4tWw56aexlkIdm5sFqpzWZJ+k++pmT8pNeAWbA9ibJy6kg7L B6YEirtCxGlF+7OrpXJR2YsAlXCTWnN8YHZaidlBq9LrVUxTmigZlWYxEcwUk2wsDEvU ZXw/qkmViEQ8lmU6V9pIydrCVDkjLdbnmHndV+B/Lw5wMMuSzpCLTMKiFZYvaxZ4cgZn GXWOtf1HC/+5g153OYo/plgpW4pOVxLOng3eWSil6cGpm32gD0MglK8Nyr9rr36IRmYh m6nHF9jTiPNwOxMVZUXcicGpiPxAIajjKeUjPFSiI0Yu+2o0WrS/RHtnh7TIBU++DJGV TNpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JbRTMv5FB29QfaOqHuCFoP8eqbdWycZVharsUHUzx7s=; b=marlDnDfxz2gSNGApfCj79LH07kH9md0D0DAmBVBSbAG4OWJ69UkSn0Zfhb9fBLHmc Bwv7iZ6gnbRruTH8dH1pNbJCYIYkTN0RmuRCEweZy9+CT6oFi+ZAEkaAsWVTjo5+7+yn q7fDZnuv0npk0m5P6yxDnun3d/XTa7uSW0mcafAlSy/YEZGHMed5cI93C28RRnjSttgJ A7Ce9mDdO5LDsx7P7x1bxKmUHus5l++0e/mpBH1ATwgJRX60+4F5j/+irXV8c0ebtcLz Ozv91BCFDMghfrmTuUOvQ2lWbG57kTctfTehKaCmFnc6Ww8pu5H4OdUuuqF/E+ZrbzI3 4MeQ== X-Gm-Message-State: AKS2vOzL2xQLYJwRVsusnU3LGTcPrPYF9Ff13/VGYN5MklOWK5qRG2nm L93EfPvTJI4ECiF+3zwB/LuhtQ/Xsg== X-Received: by 10.37.54.4 with SMTP id d4mr2707686yba.33.1498537227811; Mon, 26 Jun 2017 21:20:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.67 with HTTP; Mon, 26 Jun 2017 21:20:26 -0700 (PDT) In-Reply-To: <506d0030-68af-468b-7b2a-2d8c6d758ce4@aol.com> References: <506d0030-68af-468b-7b2a-2d8c6d758ce4@aol.com> From: Takahiko Kawasaki Date: Tue, 27 Jun 2017 13:20:26 +0900 Message-ID: To: George Fletcher Cc: Philippe Signoret , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1b0ede2586e50552e963b7" Archived-At: Subject: Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 04:20:31 -0000 --94eb2c1b0ede2586e50552e963b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you. If it is allowed that an "unspecified" behavior can be not only "not work correctly" but also "work correctly (as if scope included openid)", the condition "REQUIRED. OpenID Connect requests MUST contain the openid scope value" is not necessary (it doesn't have to say REQUIRED and MUST). Therefore, my natural interpretation is that an "unspecified" behavior is "not work correctly". However, this is my interpretation. If the interpretation is not a majority= , I should accept that the example in "5. Definitions of Multi-Valued Response Type Combinations" is allowed as an unspecified behavior. Best Regards, Takahiko Kawasaki 2017-06-27 5:42 GMT+09:00 George Fletcher : > From section 3.1.2.1 of the OpenID Connect Core... > > scope REQUIRED. OpenID Connect requests MUST contain the openid scope > value. *If the* *openid* *scope value is not present, the behavior is > entirely unspecified.* Other scope values MAY be present. Scope values > used that are not understood by an implementation SHOULD be ignored. See > Sections 5.4 > and 11 > for > additional scope values defined by this specification. > In this light, there is no specification that covers the behavior of the > AS given the authorization request you provided. > > At least that is my reading of the specs. > > Thanks, > George > > > On 6/26/17 1:59 PM, Takahiko Kawasaki wrote: > > Thank you. Please let me ask a simplified question. > > If an authorization server returns this response (including id_token): > > HTTP/1.1 302 Found > Location: https://client.example.org/cb# > access_token=3DSlAV32hkKG > &token_type=3Dbearer > &id_token=3DeyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso > &expires_in=3D3600 > &state=3Daf0ifjsldkj > > when it receives this request (without scope=3Dopenid): > > GET /authorize? > response_type=3Did_token%20token > &client_id=3Ds6BhdRkqt3 > &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb > &state=3Daf0ifjsldkj HTTP/1.1 > Host: server.example.com > > , is the implementation of the authorization server correct? > > Best Regards, > Takahiko Kawasaki > > > 2017-06-26 21:53 GMT+09:00 Philippe Signoret com>: > >> None of the examples in that spec are _*OpenID Connect*_ authentication >> requests. They are, however, valid _*OAuth 2.0**_* authorization >> requests. The one in question demonstrates use of the >> response_mode=3Did_token, as defined in the realm of OAuth 2.0. If (and = only >> if) it had scope=3Dopenid, _*then*_ it would become an OpenID Connect au= th >> request, and the OpenID Connect specs would apply. >> >> >> >> In other words, the fact that id_token is in the response_type does _ >> *not**_ *automatically make it an OpenID Connect request. >> >> >> >> Another way of seeing it is that the OAuth 2.0 Multiple Response Type >> Encoding spec is laying some foundations, as part of the OAuth 2.0 >> framework, upon which OpenID Connect is then built. >> >> >> >> In Section 11.3. OAuth Authorization Endpoint Response Types Registry >> , the OAuth 2.0 spec >> (RFC 6749) defines a registry of response types: >> >> >> >> This specification establishes the OAuth Authorization Endpoint >> >> Response Types registry. >> >> >> >> Then, in Section 3, ID Token Response Type >> , >> OAuth 2.0 Multiple Response Types registers =E2=80=9Cid_token=E2=80=9D a= s a response type >> in that same registry: >> >> >> >> This section registers a new Response Type, the id_token, in accordance >> with the stipulations in the OAuth 2.0 specification, Section 8.4. The >> intended purpose of the id_token is that it MUST provide an assertion of >> the identity of the Resource Owner as understood by the Authorization >> Server. The assertion MUST specify a targeted audience, e.g. the request= ing >> Client. However, the specific semantics of the assertion and how it can = be >> validated are not specified in this document. >> >> >> >> Finally, on that OAuth 2.0 foundation, the OpenID Connect spec defines >> (amongst other things) that including =E2=80=9Cscope=3Dopenid=E2=80=9D i= s how the client >> indicates that this is an OpenID Connect request, makes use of the >> previously registered Response Type =E2=80=9Cid_token=E2=80=9D (in some = flows=E2=80=94other flows >> don=E2=80=99t use the =E2=80=9Cid_token=E2=80=9D response type), and pro= ceeds to specify the format >> and contents of the ID Token: >> >> >> >> OpenID Connect implements authentication as an extension to the OAuth 2.= 0 >> authorization process. Use of this extension is requested by Clients by >> including the openid scope value in the Authorization Request. >> Information about the authentication performed is returned in a *JSON >> Web Token (JWT)* >> [JWT] called >> an ID Token (see *Section 2* >> ). >> >> >> >> Philippe >> >> >> >> *From:* Takahiko Kawasaki [mailto:daru.tk@gmail.com] >> *Sent:* Monday, June 26, 2017 2:17 PM >> *To:* Philippe Signoret >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type >> Encoding Practices >> >> >> >> The response_type of the example includes id_token and it is the reason >> I've brought it up. id_token triggers Authentication Request. >> >> >> >> # The response_type in the example in Appendix A >> >> does not include id_token and so I've not mentioned it. >> >> >> >> Best, >> >> Taka >> >> >> >> >> >> >> >> 2017-06-26 17:09 GMT+09:00 Philippe Signoret < >> Philippe.Signoret@microsoft.com>: >> >> scope=3Dopenid is required for OpenID Connect Authentication Requests >> (e.g. "3.3.2.1. Authentication Request >> " >> in "OpenID Connect Core 1.0 >> "), >> but not for an OAuth 2.0 Authorization Request (e.g. "4.1.1. >> Authorization Request >> " >> in "RFC6749 The OAuth 2.0 Authorization Framework >> >> "). >> >> >> >> OpenID Connect is =E2=80=9Can identity layer on top of the OAuth 2.0 pro= tocol=E2=80=9D. >> OpenID Connect specs will often refer to aspects of the OAuth 2.0 protoc= ol, >> but the OAuth 2.0 specs will generally not refer to the OpenID Connect >> constructs. (Because OpenID Connect is a specific case of OAuth 2.0.) >> >> >> >> Philippe >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Takahiko >> Kawasaki >> *Sent:* Monday, June 26, 2017 7:46 AM >> *To:* oauth@ietf.org >> *Subject:* [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type >> Encoding Practices >> >> >> >> Hello, >> >> >> >> I'm not so sure that this is the right place to ask, but I'm wondering >> whether it is correct or not that the following non-normative example fo= und >> in "5. Definitions of Multi-Valued Response Type Combinations >> " >> in "OAuth 2.0 Multiple Response Type Encoding Practices >> " >> does not include "scope=3Dopenid". >> >> >> >> GET /authorize? >> >> response_type=3Did_token%20token >> >> &client_id=3Ds6BhdRkqt3 >> >> &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org %2Fcb >> >> &state=3Daf0ifjsldkj HTTP/1.1 >> >> Host: server.example.com >> >> >> >> The reason I'm wondering is that "3.3.2.1. Authentication Request >> " >> in "OpenID Connect Core 1.0 >> " >> requires Authentication Requests be made as defined in "3.1.2.1. >> Authentication Request >> " >> and "3.1.2.1" requires the scope request parameter contain openid. >> >> >> >> >> >> Best Regards, >> >> Takahiko Kawasaki >> >> >> >> >> > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > --94eb2c1b0ede2586e50552e963b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thank you.


If it is allowed that an "unsp= ecified" behavior can be not only "not work correctly" but a= lso "work correctly (as if scope included openid)",= the condition "REQUIRED. OpenID Connect requests MUST contain = the openid scope value" is not necessary (it does= n't have to say REQUIRED and MUST). Therefore, my natural interpretation is that an "unspecified&qu= ot; behavior is "not work correctly".


However, this = is my interpretation. If the interpretation is not a majority= , I should accept that the example in "5. Definitions of Multi-= Valued Response Type Combinations" is allowed as an unspecified behavi= or.


Best Regards,<= /p>

Takahiko Kawasaki


2017-06-27 5:42 GMT+09:00= George Fletcher <gffletch@aol.com>:
=20 =20 =20
From section 3.1.2.1 of the OpenID Connect Core...

=20
scope
REQUIRED. OpenID Connect requests MUST contain= the=C2=A0openid=C2=A0scope value. If the=C2=A0openid=C2=A0scope value is not present, the behavior is entirely unspecified. Other scope values MAY be present. Scope values used that are not understood by an implementation SHOULD be ignored. See Sections= =C2=A05.4=C2=A0and=C2=A01= 1=C2=A0for additional scope values defined by this specification.

In this light, there is no specification that covers the behavior of the AS given the authorization request you provided.


At least that is my reading of the specs.

Thanks,
George


On 6/26/17 1:59 PM= , Takahiko Kawasaki wrote:
Thank you. Please let me ask a simplified question.

If an authorization server returns this response (including id_token):
  HTTP/1.1 302 Found
  Location: ht=
tps://client.example.org/cb#
  access_token=3DSlAV32hkKG
  &token_type=3Dbearer
  &id_token=3DeyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3D3600
  &state=3Daf0ifjsldkj
when it receives this request (without scope=3Dopenid):
  GET /aut=
horize?
    response_type=3Did_token%20token
    &client_id=3Ds6BhdRkqt3
    &redirect_uri=3Dhttps%3A%2F%2Fclient.example.org%2Fcb
    &state=3Daf0ifjsldkj HTTP/1.1
  Host: server.exam=
ple.com
, is the implementation of the authorization server correct?

Best Regards,
Takahiko Kawasaki


2017-06-26 21:53 GMT+09:00 Philippe Signoret <Philippe.Signoret@microsoft.com= >:

None of the examples in that spec are _OpenID Connect= _ authentication requests. They are, however, valid _O= Auth 2.0_ authorization requests. The one in question demonstrates use of the response_mode=3Did_token, as defined in the realm of OAuth 2.0. If (and only if) it had scope=3Dopenid, _= then_ it would become an OpenID Connect auth request, and the OpenID Connect specs would apply.

=C2=A0

In other words, the fact that id_token is in the response_type does _not_ automatically make it an OpenID Connect request.

=C2=A0

Another way of seeing it is that the OAuth 2.0 Multiple Response Type Encoding spec is laying some foundations, as part of the OAuth 2.0 framework, upon which OpenID Connect is then built.

=C2=A0

In Section 11.3. OAuth Authorization Endpoint Response Types Registry, the OAuth 2.0 spec (RFC 6749) defines a registry of response types:

=C2=A0

=C2=A0=C2=A0 This specification establishes the OAuth Authorization Endpoint

=C2=A0=C2=A0 Response Types registry.

=C2=A0

Then, in Section 3, ID Token Response Type, OAuth 2.0 Multiple Response Types registers =E2=80=9Cid_token=E2= =80=9D as a response type in that same registry:

=C2=A0

This section registers a new Response Type, the=C2=A0id_token, in accordance= with the stipulations in the OAuth 2.0 specification, Section 8.4. The intended purpose of the= =C2=A0id_token=C2=A0is that it MUST = provide an assertion of the identity of the Resource Owner as understood by the Authorization Server. The assertion MUST specify a targeted audience, e.g. the requesting Client. However, the specific semantics of the assertion and how it can be validated are not specified in this document.<= span style=3D"font-size:9.0pt">

=C2=A0

Finally, on that OAuth 2.0 foundation, the OpenID Connect spec defines (amongst other things) that including =E2=80=9Cscope=3Dopenid=E2=80=9D is how the client indi= cates that this is an OpenID Connect request, makes use of the previously registered Response Type =E2=80=9Cid_token= =E2=80=9D (in some flows=E2=80=94other flows don=E2=80=99t use the = =E2=80=9Cid_token=E2=80=9D response type), and proceeds to specify the format and contents of the ID Token:

=C2=A0

OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. Use of this extension is requested by Clients by including the=C2=A0openid=C2=A0scope value in the Authorization Request. Information about the authentication performed is returned in a=C2=A0JSON Web Token (JWT)=C2=A0[JWT] called an ID T= oken (see=C2=A0Section=C2=A02).

=C2=A0

Philippe

=C2=A0

From: Takahiko Kawasaki [mailto:daru.tk@gmail.com]
Sent: Monday, June 26, 2017 2:17 PM
To: Philippe Signoret <Philippe.Signoret@microsoft.= com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

=C2=A0

The response_type of the example includes id_token and it is the reason I've brought it up. id_token triggers Authentication Request.

=C2=A0

# The response_type in the example in Appendix A does not include id_token and so I've not mentioned it.

=C2=A0

Best,

Taka

=C2=A0

=C2=A0

=C2=A0

2017-06-26 17:09 GMT+09:00 Philippe Signoret <Philippe.Signoret@microsoft.com>:

scope=3Dopenid is required for OpenID Connect Authentication Requests (e.g. "3.3.2.1. Authentication Request" in &qu= ot;OpenID Connect Core 1.0"), but not for an OAuth 2.= 0 Authorization Request (e.g. "4.1.1.=C2=A0 Authorization Request" in &quo= t;RFC6749 = The OAuth 2.0 Authorization Framework").=

=C2=A0

OpenID Connect is =E2=80=9Can identity layer on = top of the OAuth 2.0 protocol=E2=80=9D. OpenI= D Connect specs will often refer to aspects of the OAuth 2.0 protocol, but the OAuth 2.0 specs will generally not refer to the OpenID Connect constructs. (Because OpenID Connect is a specific case of OAuth 2.0.)

=C2=A0

Philippe

= =C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Takahiko Kawasaki
Sent: Monday, June 26, 2017 7:46 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

=C2=A0

Hello,

=C2=A0

I'm not so sure that this is the right place to ask, but I'm wondering whether it is correct or not that the following non-normative example found in "5. Definitions of Multi-Valued Response Type Combinations" in "<= a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2= Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html&data=3D= 02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b= 163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sda= ta=3Doax1ui3n46P2n67Mqx14t0458TZjrcw9IUsdCoGsmho%3D&reserved=3D0" targe= t=3D"_blank">OAuth 2.0 Multiple Response Type Encoding Practices" does not include "scope=3Dope= nid".

=C2=A0

=C2=A0 GET /authorize?
=C2=A0=C2=A0=C2=A0 response_type=3Did_token%20toke=
n
=C2=A0=C2=A0=C2=A0 &client_id=3Ds6BhdRkqt3
=C2=A0=C2=A0=C2=A0 &redirect_uri=3Dhttps%3A%2F=
%2Fclient.example.org=
%2Fcb
=C2=A0=C2=A0=
=C2=A0 &state=3Daf0ifjsldkj HTTP/1.1
=C2=A0 Host: =
server.example.com

=C2=A0

The reason I'm wondering is that "3.3.2.1. Authentication Request" in "OpenID Connect Core 1.0" requires Authentication Requests be made as def= ined in "3.1.2.1. Authentication Request" and "3.1.2.1" requires the scope request parameter contain openid.

=C2=A0

=C2=A0

Best Regards,

Takahiko Kawasaki

=C2=A0

=C2=A0

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

--94eb2c1b0ede2586e50552e963b7-- From nobody Wed Jun 28 05:27:16 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7480612EC28 for ; Wed, 28 Jun 2017 05:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UUCEg4Z2e2R for ; Wed, 28 Jun 2017 05:27:12 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 62738129AC5 for ; Wed, 28 Jun 2017 05:27:03 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r126so31951680vkg.0 for ; Wed, 28 Jun 2017 05:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2a84I3RbHRQ3Q8jtdEHqwlrFmyaSV+VB/XsPACTRwNw=; b=IY1NuoJwlubzOZ/BdgTW5uC44V5jToet78USrr0yql/PRDiG7Qiu6NREaUBT78rlaO mhfpe4LbRLGizFmxFy0tl0M1eYs2AmlHI0qXM6Bv7VIUFVcZ2jHjI3hsN80CA73xQWm4 1LbMudzs74zbAuMIvMkQubyc2BR4X8TaIIkkwUrdrvBVLf01M+oIHOioP0PfUMVyHfmo wdObVBdRohU0ctSSfCcA/KUuRhquSd14JU+XwySITmBsd+gGkCD1/ET6wnFAkd1ubtke KF6sVc9TVN71WCobT1pYMKkTVTdeIgdKqOWisazyVcIAwFjmTeKHm75+bDa6wwr7/ewW fKkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=2a84I3RbHRQ3Q8jtdEHqwlrFmyaSV+VB/XsPACTRwNw=; b=PJu0U8qE5a8sogsjN5lQtrmS2hGYtyBp/7ZJposPnlsnMMjeTjl352boF1RjuCb2AD 73fz15Hi0duEed80s5g56VgtKQWsyJ7d7s0L5SfGW4Hcs4P4cKYMhCchPDDqXCUtzMks Pk2FE+7TghnShECXBWC2AaLEPuljzSTujJ2Ymb4C9rxk+K4+YEs6VqdqLAowwxwJvxZ7 Nhf3u10eBNi3omsozgHg0wCk+i5uXnW1ndgZgILyrXCGOZWRAQepMdRjQ0EKoLVlkqA5 OXFeM50ZmbYUIW6P+OhY54oYdpImJgGlLzYsZjXQHm9ln6Ia3FdXxGKunMxgGq89saAl ZerA== X-Gm-Message-State: AKS2vOwg1O6JyXqfMDk26wjGGFDSDgvfmO4ympFakCrjNuL+8dMgxNXu YdJRur6Dfmah2OfHtGUM8eHQlc/Mo2YD X-Received: by 10.31.59.9 with SMTP id i9mr4739986vka.64.1498652822268; Wed, 28 Jun 2017 05:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Wed, 28 Jun 2017 05:27:01 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Wed, 28 Jun 2017 08:27:01 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a114419001cf4230553044dc7" Archived-At: Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 12:27:14 -0000 --001a114419001cf4230553044dc7 Content-Type: text/plain; charset="UTF-8" Hi (as individual), I have reviewed the Device Flow document, and I have a question about the polling part. The current draft is calling for the Device Client to poll the AS for a token (steps E & F of Figure 1). Presumably, the process started with the user pushing some button on the Device Client to initiate the process. One way to avoid the need for polling is for the Device Access Token Request to be sent to the AS only after the user for example pushed that same button again. This would allow the user to perform steps C and D to authorize the device, and then push the button again to get the token. Thoughts? Regards, Rifaat On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef wrote: > All, > > We are starting a WGLC on the Device Flow document: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 > > Please, review the document and provide feedback on any issues you see > with the document. > > The WGCL will end in two weeks, on June 16, 2017. > > Regards, > Rifaat and Hannes > --001a114419001cf4230553044dc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi (as individual),

I have r= eviewed the Device Flow document, and I have a question about the polling p= art.
The current draft is calling for the Device Client to poll t= he AS for a token (steps E & F of Figure 1).

P= resumably, the process started with the user pushing some button on the Dev= ice Client to initiate the process.
One way to avoid the need for= polling is for the Device Access Token Request to be sent to the AS only a= fter the user for example pushed that same button again.
This wou= ld allow the user to perform steps C and D to authorize the device, and the= n push the button again to get the token.

Thoughts= ?

Regards,
=C2=A0Rifaat


On Thu,= Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All= ,

We are starting a WGLC on the Device Flow document:

Please, review the docum= ent and provide feedback on any issues you see with the document.

The WGCL will end in two weeks, on June 16, 2017.
=

Regards,
=C2=A0Rifaat and Hannes

--001a114419001cf4230553044dc7-- From nobody Wed Jun 28 08:33:37 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB9C12EC53 for ; Wed, 28 Jun 2017 08:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35KMf_dU21eF for ; Wed, 28 Jun 2017 08:33:33 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C79E12EC4E for ; Wed, 28 Jun 2017 08:33:33 -0700 (PDT) X-AuditID: 1209190f-ebbff700000023ec-c2-5953cc4bac47 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 D1.D4.09196.B4CC3595; Wed, 28 Jun 2017 11:33:32 -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 v5SFXUuQ017031; Wed, 28 Jun 2017 11:33:31 -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 v5SFXS7s028220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2017 11:33:29 -0400 From: Justin Richer Message-Id: <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_CE381758-5A46-452E-8CA1-B81FD7B4ADA5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 28 Jun 2017 11:33:28 -0400 In-Reply-To: Cc: "" To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1vU5Exxp0LOM2+Lk21dsFjtftLI5 MHnsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBkbOtQKJppW3Nq0lrmBcZNuFyMnh4SAiUT/ 4otsXYxcHEICi5kkbvx/zAThbGSUWLl/IzuE85BJYs2WtewgLWwCqhLT17Qwgdi8AlYST+7d YgGxmQWSJPa//cvcxcgBFNeX6H3OCBIWFrCRWPJ3J5jNAtT68tQisHJOgUCJnc9/gpUzC6hL tJ90AQmLCOhJtP9dCHXDdEaJqevnsUNcKitxa/Yl5gmM/LOQbJuFsA0irC2xbOFrZghbU2J/ 93IWTHENic5vE1kXMLKtYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECA5qSf4d jHMavA8xCnAwKvHwMqwNjhRiTSwrrsw9xCjJwaQkyrv3S1CkEF9SfkplRmJxRnxRaU5q8SFG CQ5mJRHe1oVA5bwpiZVVqUX5MClpDhYlcV5xjcYIIYH0xJLU7NTUgtQimKwMB4eSBK/naaBG waLU9NSKtMycEoQ0EwcnyHAeoOGdJ0CGFxck5hZnpkPkTzHqcizo2fCFSYglLz8vVUqcVwxk kABIUUZpHtwcUDJKeHvY9BWjONBbwrxeIFU8wEQGN+kV0BImoCUs8wJAlpQkIqSkGhj9irOu zJ9hoxnNOLHW2JxvWc22BeorHS3L26OU/FdaapY/PPNj1z2pg/2KKtZCcWZBU3u/P5rY18n1 eTXv9WdnbntNvrbi/YqaNfstjp/mPXvj6vl1E3eUM5tdbfm9VvVnS/v7yhNLmy0M9DewZL9J 8lOd/rrpE4Pjq1Sft46VYmJLJ/bJ7U1WYinOSDTUYi4qTgQAv5FU6SEDAAA= Archived-At: Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 15:33:36 -0000 --Apple-Mail=_CE381758-5A46-452E-8CA1-B81FD7B4ADA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is functionally equivalent to polling, as far as the spec is = concerned. Instead of it being a timeout-based poll, it=E2=80=99s an = interaction-based poll. Either way, the device makes a new HTTP request = to the AS to see if the device code is good or not, and either option is = possible at that point as far as the device knows=E2=80=94 the user = could go mash buttons as fast as possible without ever entering the user = code. In practice, this isn=E2=80=99t very likely to happen, as it requires = additional steps for the user and makes for a more clunky experience. If = anything, we might see it as an optimization in some environments for = some clients. In any event, it=E2=80=99s not any different from the = spec=E2=80=99s perspective. =E2=80=94 Justin > On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef = wrote: >=20 > Hi (as individual), >=20 > I have reviewed the Device Flow document, and I have a question about = the polling part. > The current draft is calling for the Device Client to poll the AS for = a token (steps E & F of Figure 1). >=20 > Presumably, the process started with the user pushing some button on = the Device Client to initiate the process. > One way to avoid the need for polling is for the Device Access Token = Request to be sent to the AS only after the user for example pushed that = same button again. > This would allow the user to perform steps C and D to authorize the = device, and then push the button again to get the token. >=20 > Thoughts? >=20 > Regards, > Rifaat >=20 >=20 > On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef = > wrote: > All, >=20 > We are starting a WGLC on the Device Flow document: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 = >=20 > Please, review the document and provide feedback on any issues you see = with the document. >=20 > The WGCL will end in two weeks, on June 16, 2017. >=20 > Regards, > Rifaat and Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_CE381758-5A46-452E-8CA1-B81FD7B4ADA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is functionally equivalent to polling, as far as the = spec is concerned. Instead of it being a timeout-based poll, it=E2=80=99s = an interaction-based poll. Either way, the device makes a new HTTP = request to the AS to see if the device code is good or not, and either = option is possible at that point as far as the device knows=E2=80=94 the = user could go mash buttons as fast as possible without ever entering the = user code.

In = practice, this isn=E2=80=99t very likely to happen, as it requires = additional steps for the user and makes for a more clunky experience. If = anything, we might see it as an optimization in some environments for = some clients. In any event, it=E2=80=99s not any different from the = spec=E2=80=99s perspective.

 =E2=80=94 Justin

On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hi (as = individual),

I = have reviewed the Device Flow document, and I have a question about the = polling part.
The current draft is calling for the = Device Client to poll the AS for a token (steps E & F of Figure = 1).

Presumably, = the process started with the user pushing some button on the Device = Client to initiate the process.
One way to avoid = the need for polling is for the Device Access Token Request to be sent = to the AS only after the user for example pushed that same button = again.
This would allow the user to perform steps C = and D to authorize the device, and then push the button again to get the = token.

Thoughts?

Regards,
 Rifaat


On Thu, Jun 1, 2017 at 8:32 AM, = Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

We = are starting a WGLC on the Device Flow document:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06

Please, review the document and provide feedback on any = issues you see with the document.

The WGCL will end in two weeks, on June = 16, 2017.

Regards,
 Rifaat and = Hannes

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

= --Apple-Mail=_CE381758-5A46-452E-8CA1-B81FD7B4ADA5-- From nobody Wed Jun 28 11:35:46 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8601A12EBF5 for ; Wed, 28 Jun 2017 11:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMblj5-VPme6 for ; Wed, 28 Jun 2017 11:35:36 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 3311112EC08 for ; Wed, 28 Jun 2017 11:35:35 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id y70so37672431vky.3 for ; Wed, 28 Jun 2017 11:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ToKFdGjz2Cru++7h5LprC6t+RBmCY47Ys0vquzfOFh4=; b=T+QuqQj175+7dVQgxeC+Ch1V9b+/Q6H9t5v4lgsZJwhBlTNbpd2kfD8edWB7bc6x4L u1UvN5qDePdcJr6crWDrktFyAA6MwuEYyPTT/6bUFLe2PhZWKbcRmqhtA6HzalqIXZET 47OuNGAP+X/Dhua71bsuLkAEOBJ/j2vNBY0BCK9BK4oV+hxQICKrOqPKYgszGf2prdvC hhUyArGbSrHXeFMBh9xRkxGNwJ5bIQFDwDPss00kVLrCc07+fi45nHpj26j3nuyf7RsG tDV5iD0m+RaliIq6btq1z1ePfiqxq51z1fyQCD0+fK3QmrRqnO0TYa4w4c3H5yhhdmZu Fkfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ToKFdGjz2Cru++7h5LprC6t+RBmCY47Ys0vquzfOFh4=; b=FXNfrGj7cWtkFrU33QZ7p2RMiSeKUhhijZlpxX2008YIPH7+/Yh94A+8cjPGlzfLP4 tGxrkSISqP4bs3O1PIMkvGeBLtRhBATbBeeRib4ypDDde7XW1A12cXfIY4trfSExEurC f87mJjztWQcsT8uS9nqvBzKscV2xdPzvYdWsu1qrvHpEdKUWocLd0wXUAJNEb8FSYjBA vHLpSa6xe6N8YRAochdpNqdixJkxqexRn/uEOa5j3dbaQWCT0mScej7TwaluuJXRlW7c 3UfE/LDUTVZYurDbu2LZBVPj28gVC6WgRXkucB+gL6gMhcHZmvPzN9fy0jcL4xkDPGW7 6tHg== X-Gm-Message-State: AKS2vOzb3Kk+Uw/MeJUGlseTLQ5bXqx3HBlrtZriVYS0vYBz4micE073 QMydZ6LuSrA5aaTxNvXyAhxjnoM1NA== X-Received: by 10.31.56.132 with SMTP id f126mr3533616vka.86.1498674934317; Wed, 28 Jun 2017 11:35:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Wed, 28 Jun 2017 11:35:33 -0700 (PDT) In-Reply-To: <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu> References: <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu> From: Rifaat Shekh-Yusef Date: Wed, 28 Jun 2017 14:35:33 -0400 Message-ID: To: Justin Richer Cc: "" Content-Type: multipart/alternative; boundary="001a11431040180e130553097347" Archived-At: Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 18:35:38 -0000 --001a11431040180e130553097347 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 28, 2017 at 11:33 AM, Justin Richer wrote: > This is functionally equivalent to polling, as far as the spec is > concerned. Instead of it being a timeout-based poll, it=E2=80=99s an > interaction-based poll. Either way, the device makes a new HTTP request t= o > the AS to see if the device code is good or not, and either option is > possible at that point as far as the device knows=E2=80=94 the user could= go mash > buttons as fast as possible without ever entering the user code. > > You are correct that this does not change the communication model, but if there is a large number of devices being configured at the same time, then the polling as it is defined in the document unnecessarily overloads the AS whether the user is doing anything or not. > In practice, this isn=E2=80=99t very likely to happen, as it requires add= itional > steps for the user and > It requires one more step (not steps), which is the user pushing the button one more time after the user is done with authenticating and authorizing the device; do you see any other steps needed here? > makes for a more clunky experience. > I guess this is subjective, but why do you think it is clunky? Regards,. Rifaat > If anything, we might see it as an optimization in some environments for > some clients. In any event, it=E2=80=99s not any different from the spec= =E2=80=99s > perspective. > > =E2=80=94 Justin > > On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef > wrote: > > Hi (as individual), > > I have reviewed the Device Flow document, and I have a question about the > polling part. > The current draft is calling for the Device Client to poll the AS for a > token (steps E & F of Figure 1). > > Presumably, the process started with the user pushing some button on the > Device Client to initiate the process. > One way to avoid the need for polling is for the Device Access Token > Request to be sent to the AS only after the user for example pushed that > same button again. > This would allow the user to perform steps C and D to authorize the > device, and then push the button again to get the token. > > Thoughts? > > Regards, > Rifaat > > > On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef > wrote: > >> All, >> >> We are starting a WGLC on the Device Flow document: >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 >> >> Please, review the document and provide feedback on any issues you see >> with the document. >> >> The WGCL will end in two weeks, on June 16, 2017. >> >> Regards, >> Rifaat and Hannes >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11431040180e130553097347 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Jun 28, 2017 at 11:33 AM, Justin Richer <jricher@mit.edu> wrote:
This is functionally equivalent to polling, as fa= r as the spec is concerned. Instead of it being a timeout-based poll, it=E2= =80=99s an interaction-based poll. Either way, the device makes a new HTTP = request to the AS to see if the device code is good or not, and either opti= on is possible at that point as far as the device knows=E2=80=94 the user c= ould go mash buttons as fast as possible without ever entering the user cod= e.


You are correct tha= t this does not change the communication model, but if there is a large num= ber of devices being configured at the same time, then the polling as it is= defined in the document unnecessarily overloads the AS whether the user is= doing anything or not.

=C2=A0
In practice, this isn=E2=80=99t very likely to happen, as it r= equires additional steps for the user and
It requires one more step (not steps), which is the user pushin= g the button one more time after the user is done with authenticating and a= uthorizing the device; do you see any other steps needed here?

=C2=A0
makes for a more clunky experi= ence.

I guess this is subjecti= ve, but why do you think it is clunky?

Regards= ,.
=C2=A0Rifaat


=C2=A0
If anything, we might see it as an optimization in some = environments for some clients. In any event, it=E2=80=99s not any different= from the spec=E2=80=99s perspective.

=C2=A0=E2=80= =94 Justin

On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:





On Thu, Jun 1, 2017 at 8:= 32 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:=
All,=

We are starting a WGLC on the Device Flow document:

Please, review the document an= d provide feedback on any issues you see with the document.

<= /div>
The WGCL will end in two weeks, on June 16, 2017.
<= br>
Regards,
=C2=A0Rifaat and Hannes

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


--001a11431040180e130553097347-- From nobody Wed Jun 28 13:45:48 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A07112EB1F for ; Wed, 28 Jun 2017 13:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkiPI9Fu4HVe for ; Wed, 28 Jun 2017 13:45:45 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.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 35D701270AC for ; Wed, 28 Jun 2017 13:45:45 -0700 (PDT) X-AuditID: 12074423-40dff70000003249-6a-59541577bc21 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id BF.61.12873.77514595; Wed, 28 Jun 2017 16:45:43 -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 v5SKjfwe014224; Wed, 28 Jun 2017 16:45:42 -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 v5SKjdpr012264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2017 16:45:41 -0400 From: Justin Richer Message-Id: <8C46E20E-EFF4-481A-99E7-ADD1A9DF133F@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_0B88D72B-044A-4328-B273-24A6FF5DFFA5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 28 Jun 2017 16:45:40 -0400 In-Reply-To: Cc: "" To: Rifaat Shekh-Yusef References: <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hRV1i0XDYk0aLmnZ3Hy7Ss2i50vWtkc mDx2zrrL7rFkyU+mAKYoLpuU1JzMstQifbsErozND18yFuyqr3i2cRtbA+P5nC5GTg4JAROJ F6umsHUxcnEICSxmkth3cj4LSEJIYCOjxLO9zhCJh0wSG3t+gCXYBFQlpq9pYQKxeQWsJBbM /M8GYjMLJEmsun4eKM4BFNeX6H3OCBIWFrCRWPJ3J5jNAtR6aOl6VhCbUyBQ4uLK9Wwg5cwC 6hLtJ11AwiICehLtfxcyQaztZ5Jov/2XHeJQWYlbsy8xT2Dkn4Vk2yyEbRBhbYllC18zQ9ia Evu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJeXmqRrplebmaJXmpK6SZGUFCz uyjvYHzZ532IUYCDUYmHl2FtcKQQa2JZcWXuIUZJDiYlUd4j74FCfEn5KZUZicUZ8UWlOanF hxglOJiVRHgrzgLleFMSK6tSi/JhUtIcLErivOIajRFCAumJJanZqakFqUUwWRkODiUJXneR kEghwaLU9NSKtMycEoQ0EwcnyHAeoOEq/EA1vMUFibnFmekQ+VOMuhwLejZ8YRJiycvPS5US 5zUBGSQAUpRRmgc3B5SMEt4eNn3FKA70ljAvG0gVDzCRwU16BbSECWgJy7wAkCUliQgpqQZG hzTOQw7c0+u4/8y81H9z/h7fXIG68Nt55XNvmk9i6+CxuDBfa3/0ZMU7c4tWL7eYwL1H6VDv /p+JtTe/mMVpaPKcXrF+Qs7EFuOlS+easem+YC06r1vop1rW3Pfkf5v4co8J9+PmJilMvJqt WLVC5LNy3LxwieiYWdJ3jjk8U9x00NnCdUeoEktxRqKhFnNRcSIAAFXQnSEDAAA= Archived-At: Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 20:45:47 -0000 --Apple-Mail=_0B88D72B-044A-4328-B273-24A6FF5DFFA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 28, 2017, at 2:35 PM, Rifaat Shekh-Yusef = wrote: >=20 >=20 > On Wed, Jun 28, 2017 at 11:33 AM, Justin Richer > wrote: > This is functionally equivalent to polling, as far as the spec is = concerned. Instead of it being a timeout-based poll, it=E2=80=99s an = interaction-based poll. Either way, the device makes a new HTTP request = to the AS to see if the device code is good or not, and either option is = possible at that point as far as the device knows=E2=80=94 the user = could go mash buttons as fast as possible without ever entering the user = code. >=20 >=20 > You are correct that this does not change the communication model, but = if there is a large number of devices being configured at the same time, = then the polling as it is defined in the document unnecessarily = overloads the AS whether the user is doing anything or not. >=20 The polling mechanism already has slow-down and other mechanisms to = prevent the AS from being unnecessarily overloaded by well-behaved = clients.=20 > =20 > In practice, this isn=E2=80=99t very likely to happen, as it requires = additional steps for the user and >=20 > It requires one more step (not steps), which is the user pushing the = button one more time after the user is done with authenticating and = authorizing the device; do you see any other steps needed here? >=20 What you describe as =E2=80=9Cclicking the button=E2=80=9D really = isn=E2=80=99t that simple in the real world: 1) Being told I need to go click a button by the AS, or maybe I need to = go click a button, because now we have something that=E2=80=99s device = specific and would be tied to the device registration. After all, some = things will be =E2=80=9Cautomatic=E2=80=9D per the user=E2=80=99s = experience (because of polling) and some will require further actions. 2) Finding the device because I wasn=E2=80=99t at the device I was at my = computer and maybe the device needs me to do something else or maybe not = (see step 1) 3) Finding the button on the device, or is that one the power button? Or = does this one require me to wave my hand in front of a sensor instead of = a button? Maybe there are some instructions on the device, or it will = talk to me and tell me what to do when I push the button. 4) Clicking the button. Or waving my hand. Or shaking it really hard. Or = licking it. 5) Checking to see if it worked, maybe clicking the button again just in = case... > =20 > makes for a more clunky experience. >=20 > I guess this is subjective, but why do you think it is clunky? See the process above. It=E2=80=99s going to be incredibly device = specific and not something we can, or should address at the protocol = level, especially since the protocol as-is already allows for = action-based polling completely transparently to the rest of the system.=20= I don=E2=80=99t see any need for changes to the document to accommodate = this. I would not be against a very small note that polling could happen = on a reactive basis from the device instead of a timer, perhaps adding = something like this sentence to =C2=A73.3=C2=B63: Common mechanisms for determining when to poll include use of an = internal timer and reliance on an interaction with the user, such as a = button click or other physical activation. The details of such reactive = polling behavior are expected to be device specific and are therefore = outside the scope of this specification.=20 Thanks, =E2=80=94 Justin >=20 > Regards,. > Rifaat >=20 >=20 > =20 > If anything, we might see it as an optimization in some environments = for some clients. In any event, it=E2=80=99s not any different from the = spec=E2=80=99s perspective. >=20 > =E2=80=94 Justin >=20 >> On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef = > wrote: >>=20 >> Hi (as individual), >>=20 >> I have reviewed the Device Flow document, and I have a question about = the polling part. >> The current draft is calling for the Device Client to poll the AS for = a token (steps E & F of Figure 1). >>=20 >> Presumably, the process started with the user pushing some button on = the Device Client to initiate the process. >> One way to avoid the need for polling is for the Device Access Token = Request to be sent to the AS only after the user for example pushed that = same button again. >> This would allow the user to perform steps C and D to authorize the = device, and then push the button again to get the token. >>=20 >> Thoughts? >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef = > wrote: >> All, >>=20 >> We are starting a WGLC on the Device Flow document: >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 = >>=20 >> Please, review the document and provide feedback on any issues you = see with the document. >>=20 >> The WGCL will end in two weeks, on June 16, 2017. >>=20 >> Regards, >> Rifaat and Hannes >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_0B88D72B-044A-4328-B273-24A6FF5DFFA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 28, 2017, at 2:35 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:


On Wed, Jun 28, 2017 at 11:33 AM, = Justin Richer <jricher@mit.edu> wrote:
This is functionally = equivalent to polling, as far as the spec is concerned. Instead of it = being a timeout-based poll, it=E2=80=99s an interaction-based poll. = Either way, the device makes a new HTTP request to the AS to see if the = device code is good or not, and either option is possible at that point = as far as the device knows=E2=80=94 the user could go mash buttons as = fast as possible without ever entering the user code.


You are correct that this does not = change the communication model, but if there is a large number of = devices being configured at the same time, then the polling as it is = defined in the document unnecessarily overloads the AS whether the user = is doing anything or not.


The polling mechanism already has slow-down and = other mechanisms to prevent the AS from being unnecessarily overloaded = by well-behaved clients. 

 
In practice, this = isn=E2=80=99t very likely to happen, as it requires additional steps for = the user and

It requires one more step (not steps), = which is the user pushing the button one more time after the user is = done with authenticating and authorizing the device; do you see any = other steps needed here?


What you describe as =E2=80=9Cclicking the = button=E2=80=9D really isn=E2=80=99t that simple in the real = world:

1) Being told I need to go = click a button by the AS, or maybe I need to go click a button, because = now we have something that=E2=80=99s device specific and would be tied = to the device registration. After all, some things will be = =E2=80=9Cautomatic=E2=80=9D per the user=E2=80=99s experience (because = of polling) and some will require further actions.
2) Finding = the device because I wasn=E2=80=99t at the device I was at my computer = and maybe the device needs me to do something else or maybe not (see = step 1)
3) Finding the button on the device, or is that one = the power button? Or does this one require me to wave my hand in front = of a sensor instead of a button? Maybe there are some instructions on = the device, or it will talk to me and tell me what to do when I push the = button.
4) Clicking the button. Or waving my hand. Or shaking = it really hard. Or licking it.
5) Checking to see if it = worked, maybe clicking the button again just in case...


 
makes for a = more clunky experience.

I guess this is subjective, but why do = you think it is clunky?

See the process above. It=E2=80=99s going to be = incredibly device specific and not something we can, or should address = at the protocol level, especially since the protocol as-is already = allows for action-based polling completely transparently to the rest of = the system. 

I don=E2=80=99t = see any need for changes to the document to accommodate this. I would = not be against a very small note that polling could happen on a reactive = basis from the device instead of a timer, perhaps adding something like = this sentence to =C2=A73.3=C2=B63:

Common mechanisms for = determining when to poll include use of an internal timer and reliance = on an interaction with the user, such as a button click or other = physical activation. The details of such reactive polling behavior are = expected to be device specific and are therefore outside the scope of = this specification. 

Thanks,

 =E2=80=94 Justin



Regards,.
 Rifaat


 
If anything, we might see it as an = optimization in some environments for some clients. In any event, it=E2=80= =99s not any different from the spec=E2=80=99s perspective.

 =E2=80= =94 Justin

On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hi (as individual),

I have reviewed the Device Flow = document, and I have a question about the polling part.
The current draft is calling for the Device Client to poll = the AS for a token (steps E & F of Figure 1).
Presumably, the process started with = the user pushing some button on the Device Client to initiate the = process.
One way to avoid the need for polling is = for the Device Access Token Request to be sent to the AS only after the = user for example pushed that same button again.
This = would allow the user to perform steps C and D to authorize the device, = and then push the button again to get the token.

Thoughts?

Regards,
 Rifaat


On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> = wrote:
All,

We are starting a WGLC = on the Device Flow document:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06

Please, review the = document and provide feedback on any issues you see with the = document.

The = WGCL will end in two weeks, on June 16, 2017.

Regards,
 Rifaat and Hannes

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



= --Apple-Mail=_0B88D72B-044A-4328-B273-24A6FF5DFFA5-- From nobody Wed Jun 28 15:24:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE512EB44 for ; Wed, 28 Jun 2017 15:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZbImqYEzgbl for ; Wed, 28 Jun 2017 15:24:49 -0700 (PDT) Received: from mr11p26im-asmtp004.me.com (mr11p26im-asmtp004.me.com [17.110.86.109]) (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 2B53B12EC71 for ; Wed, 28 Jun 2017 15:24:49 -0700 (PDT) Received: from process-dkim-sign-daemon.mr11p26im-asmtp004.me.com by mr11p26im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OSA00O003D4IJ00@mr11p26im-asmtp004.me.com> for oauth@ietf.org; Wed, 28 Jun 2017 22:24:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1498688688; bh=4L7GHOlPmFC+8HChFA29REpZDFPqccKTE9tqS+xDak0=; h=From:Content-type:MIME-version:Date:Subject:Message-id:To; b=LcP/1kZIFW7JxG2Id3keVSHf3eaIpoHaDwkGPjHb4J//lGlbfvqChPnXxRYCSscNT K13EClsXE84xLhho42lW246xIMXi7D4pNAhiAdOKJ1RETAQ8H5Y/nCfpHiFzvnOYXP Mi7JWCsAMx8+q+1hMsXCvB3LBnEJYvSfelp2RCGaNxl+wmCOsYp16Ef47cTvoVaCKi ZQcTuYjn5rC/7ajQScI8Pc4hkAja2UF4o0nd2MBTcooRLJv6Gq+osZO+DhDDwk4AVl XnXZf164ELTDxvQT/+iXZpfmj70A6BYnB447JoKarqBbXGm8GLBGR03a/INARb5uHA ILFk46sNxpd8A== Received: from icloud.com ([127.0.0.1]) by mr11p26im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OSA005CI3LARO30@mr11p26im-asmtp004.me.com> for oauth@ietf.org; Wed, 28 Jun 2017 22:24:48 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-28_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1706280359 From: =?iso-2022-jp?B?GyRCMGY+ZUQ+NSobKEI=?= Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (1.0) Date: Thu, 29 Jun 2017 07:24:45 +0900 Message-id: <5559F37F-CF65-43FE-A281-1BB8607506B0@icloud.com> References: In-reply-to: To: oauth@ietf.org X-Mailer: iPhone Mail (14F89) Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 104, Issue 30 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 22:24:57 -0000 Sent from my iPhone > On Jun 29, 2017, at 4:00, oauth-request@ietf.org wrote: >=20 > Send OAuth mailing list submissions to > oauth@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a =C3=BAt message with subject or body 'help' to > oauth-request@ietf.org >=20 > You can reach the person managing the list at > oauth-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: WGLC draft-ietf-oauth-device-flow-06 (Rifaat Shekh-Yusef) > 2. Re: WGLC draft-ietf-oauth-device-flow-06 (Justin Richer) > 3. Re: WGLC draft-ietf-oauth-device-flow-06 (Rifaat Shekh-Yusef) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Wed, 28 Jun 2017 08:27:01 -0400 > From: Rifaat Shekh-Yusef > To: oauth > Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 > Message-ID: > > Content-Type: text/plain; charset=3D"utf-8" >=20 > Hi (as individual), >=20 > I have reviewed the Device Flow document, and I have a question about the > polling part. > The current draft is calling for the Device Client to poll the AS for a > token (steps E & F of Figure 1). >=20 > Presumably, the process started with the user pushing some button on the > Device Client to initiate the process. > One way to avoid the need for polling is for the Device Access Token > Request to be sent to the AS only after the user for example pushed that > same button again. > This would allow the user to perform steps C and D to authorize the device= , > and then push the button again to get the token. >=20 > Thoughts? >=20 > Regards, > Rifaat >=20 >=20 > On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef = > wrote: >=20 >> All, >>=20 >> We are starting a WGLC on the Device Flow document: >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 >>=20 >> Please, review the document and provide feedback on any issues you see >> with the document. >>=20 >> The WGCL will end in two weeks, on June 16, 2017. >>=20 >> Regards, >> Rifaat and Hannes >>=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: >=20 > ------------------------------ >=20 > Message: 2 > Date: Wed, 28 Jun 2017 11:33:28 -0400 > From: Justin Richer > To: Rifaat Shekh-Yusef > Cc: "" > Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 > Message-ID: <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu> > Content-Type: text/plain; charset=3D"utf-8" >=20 > This is functionally equivalent to polling, as far as the spec is concerne= d. Instead of it being a timeout-based poll, it?s an interaction-based poll.= Either way, the device makes a new HTTP request to the AS to see if the dev= ice code is good or not, and either option is possible at that point as far a= s the device knows? the user could go mash buttons as fast as possible witho= ut ever entering the user code. >=20 > In practice, this isn?t very likely to happen, as it requires additional s= teps for the user and makes for a more clunky experience. If anything, we mi= ght see it as an optimization in some environments for some clients. In any e= vent, it?s not any different from the spec?s perspective. >=20 > ? Justin >=20 >> On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef w= rote: >>=20 >> Hi (as individual), >>=20 >> I have reviewed the Device Flow document, and I have a question about the= polling part. >> The current draft is calling for the Device Client to poll the AS for a t= oken (steps E & F of Figure 1). >>=20 >> Presumably, the process started with the user pushing some button on the D= evice Client to initiate the process. >> One way to avoid the need for polling is for the Device Access Token Requ= est to be sent to the AS only after the user for example pushed that same bu= tton again. >> This would allow the user to perform steps C and D to authorize the devic= e, and then push the button again to get the token. >>=20 >> Thoughts? >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef > wrote: >> All, >>=20 >> We are starting a WGLC on the Device Flow document: >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 >>=20 >> Please, review the document and provide feedback on any issues you see wi= th the document. >>=20 >> The WGCL will end in two weeks, on June 16, 2017. >>=20 >> Regards, >> Rifaat and Hannes >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: >=20 > ------------------------------ >=20 > Message: 3 > Date: Wed, 28 Jun 2017 14:35:33 -0400 > From: Rifaat Shekh-Yusef > To: Justin Richer > Cc: "" > Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 > Message-ID: > > Content-Type: text/plain; charset=3D"utf-8" >=20 >> On Wed, Jun 28, 2017 at 11:33 AM, Justin Richer wrote: >>=20 >> This is functionally equivalent to polling, as far as the spec is >> concerned. Instead of it being a timeout-based poll, it?s an >> interaction-based poll. Either way, the device makes a new HTTP request t= o >> the AS to see if the device code is good or not, and either option is >> possible at that point as far as the device knows? the user could go mash= >> buttons as fast as possible without ever entering the user code. >>=20 >>=20 > You are correct that this does not change the communication model, but if > there is a large number of devices being configured at the same time, then= > the polling as it is defined in the document unnecessarily overloads the A= S > whether the user is doing anything or not. >=20 >=20 >=20 >> In practice, this isn?t very likely to happen, as it requires additional >> steps for the user and >>=20 >=20 > It requires one more step (not steps), which is the user pushing the butto= n > one more time after the user is done with authenticating and authorizing > the device; do you see any other steps needed here? >=20 >=20 >=20 >> makes for a more clunky experience. >>=20 >=20 > I guess this is subjective, but why do you think it is clunky? >=20 > Regards,. > Rifaat >=20 >=20 >=20 >=20 >> If anything, we might see it as an optimization in some environments for >> some clients. In any event, it?s not any different from the spec?s >> perspective. >>=20 >> ? Justin >>=20 >> On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef >> wrote: >>=20 >> Hi (as individual), >>=20 >> I have reviewed the Device Flow document, and I have a question about the= >> polling part. >> The current draft is calling for the Device Client to poll the AS for a >> token (steps E & F of Figure 1). >>=20 >> Presumably, the process started with the user pushing some button on the >> Device Client to initiate the process. >> One way to avoid the need for polling is for the Device Access Token >> Request to be sent to the AS only after the user for example pushed that >> same button again. >> This would allow the user to perform steps C and D to authorize the >> device, and then push the button again to get the token. >>=20 >> Thoughts? >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef >> wrote: >>=20 >>> All, >>>=20 >>> We are starting a WGLC on the Device Flow document: >>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 >>>=20 >>> Please, review the document and provide feedback on any issues you see >>> with the document. >>>=20 >>> The WGCL will end in two weeks, on June 16, 2017. >>>=20 >>> Regards, >>> Rifaat and Hannes >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > ------------------------------ >=20 > End of OAuth Digest, Vol 104, Issue 30 > ************************************** From nobody Thu Jun 29 15:01:11 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A4D12EAFB for ; Thu, 29 Jun 2017 15:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DYMIgIfShel for ; Thu, 29 Jun 2017 15:01:04 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 9170512700F for ; Thu, 29 Jun 2017 15:01:04 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id s66so56790010pfs.1 for ; Thu, 29 Jun 2017 15:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b+NEUaCmgw4AgomYZR1m16auHuOSa3vR6V3np7xGaWw=; b=Vo1XjooXk2HhCDm6VowuRvS05Z3hLItxjs1jwQsyp8Xe+YwJ7bspuSz0nktNdO+4FU 06uVS8uI00JDRrG+rJkA4FcE9Ot+rwX8nyXSe7SAK+o/of7u/1J10Agr/+S3eqhl+B1O 3oHC8XNomrTtZ172eVS7Hap/ViYzH6M0i6XgA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b+NEUaCmgw4AgomYZR1m16auHuOSa3vR6V3np7xGaWw=; b=HWn9ETXr78xAkJBKUEN7Djid/aejFVzifiMMRipB9QaTr8N1usmPyqSC545TFcb6VH OpHP6ai6bJlF7ZgOFIt/n77624qekH1doJZ9E34iLETwtsGQc8nb62ZrkX+CI8cx4rvR ljgfm+AfkM9qs/i40ibL4w8KhmV2BcLYK7XpW3pACa+0jXJoZH6RC4j6cLnP8X8hcjLL 47snuNo4TV9HD73zsFEjqiAbwLFQ9v2hTEpgBIyJ9SsGEs4a1MEIKm4kiVgxxv6a+7F+ HA7W6amicD2SvXG1Nz2UhUzQU5NbmlXpUa97FI66VWGF+TBRLA1eI7SGQNW/gnCyX4cn VfMg== X-Gm-Message-State: AKS2vOyyczG+hfUa7gp7p64iZcVCJLrid6VAL4XkvLL6Kkwr3BW+SO81 Myvn3ek73AIJ24B90UGcwL+UJmkMzZAiI0Pt6vvxqFkkgCrfSWa415d7XseR+e1VXe8JMOqf+pc U2wrV X-Received: by 10.98.93.136 with SMTP id n8mr8383918pfj.211.1498773664089; Thu, 29 Jun 2017 15:01:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Thu, 29 Jun 2017 15:00:33 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 29 Jun 2017 16:00:33 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="001a113991a6d8e0b70553206f20" Archived-At: Subject: Re: [OAUTH-WG] Agenda requests for Prague X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 22:01:07 -0000 --001a113991a6d8e0b70553206f20 Content-Type: text/plain; charset="UTF-8" I'd like to please make agenda requests for the following documents (unless, of course, any of the co-authors want to take the slot instead of me): draft-ietf-oauth-mtls (~15 mins?) draft-ietf-oauth-token-exchange (~10 mins?) draft-ietf-oauth-token-binding (~10 mins?) Thanks, Brian On Mon, Jun 26, 2017 at 6:16 AM, Rifaat Shekh-Yusef wrote: > All, > > If you have not done so already, please send us your agenda requests for > the coming meeting in Prague. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- [image: Ping Identity] Brian Campbell Distinguished Engineer bcampbell@pingidentity.com w: +1 720.317.2061 c: +1 303.918.9415 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Google+ logo] [image: Blog logo] -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a113991a6d8e0b70553206f20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to please make agenda requests for = the following documents (unless, of course, any of the co-authors want to t= ake the slot instead of me):

=20 =20 =20 =20 draft-ietf-oauth-mtls (~15 mins?)
=20 =20 =20 =20 draft-ietf-oauth-token-exchange (~10 mi= ns?)
=20 =20 =20 =20 draft-ietf-oauth-token-binding (~10 mins?)
Thanks,
Brian

<= div class=3D"gmail_quote">On Mon, Jun 26, 2017 at 6:16 AM, Rifaat Shekh-Yus= ef <rifaat.ietf@gmail.com> wrote:
All,

If you have not done= so already, please send us your agenda requests for the coming meeting in = Prague.

Regards,
=C2=A0Rifaat & Hann= es

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




--
= = =
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a113991a6d8e0b70553206f20-- From nobody Thu Jun 29 16:39:21 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C67126BF7; Thu, 29 Jun 2017 16:39:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149877955945.4706.12349304772344508035@ietfa.amsl.com> Date: Thu, 29 Jun 2017 16:39:19 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 23:39:19 -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 of the IETF. Title : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-02.txt Pages : 13 Date : 2017-06-29 Abstract: This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for both OAuth client authentication to the token endpoint as well as for sender constrained access to OAuth protected resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-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 Thu Jun 29 16:43:36 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FBB12EAFA for ; Thu, 29 Jun 2017 16:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwV-dO5qPg-4 for ; Thu, 29 Jun 2017 16:43:32 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 9FA71128C81 for ; Thu, 29 Jun 2017 16:43:32 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id s66so57776415pfs.1 for ; Thu, 29 Jun 2017 16:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=0Px/UGoaxPg6CXJ7ieaH5J0kkR0oefb4Gwx/T5mdKtk=; b=NmNYrZe5UYLpqaML0L2A768InEuu1OvkjftAIHrg7qHMDeAA73DzbPArNGjfYJAPaI VnZSC0ChXufv28PmTy8m9BSh8m+fkE+mtVI0mNjg6s2Cbi4tu5Y+fyi4T03Uo+hLFOk0 +qRZeD50RelEqMWaz4zatxRhdekQn3ROr7I58= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=0Px/UGoaxPg6CXJ7ieaH5J0kkR0oefb4Gwx/T5mdKtk=; b=dqnHEi7PIga7I7itjleecggnoJQKhcBnoOTQ0kWjuIfpsYhgDliQeHzpuA16bQt5Js T8pQup7kiAN5XY8iSquRT1Z7+nS/j1ih5YQzkk3UkeLBTYdDGkXOe+MtTcfnvC3WyBKb oQ8gCvsRhV/DQEmZ3yw6NhneTHAiBCHkjdMEw44FmhUeaLMziCupa0ssEfAHPfyFSuF+ LkyKVQiH+6iyG/FoE/x5la8JEpBTn7IqQvjjaqD0ihxBj09yRdUZfbcTDBt1u2sL3OM5 ZIHxR3YFRAHrt3uf/sPP/ROotTwdkaQP099AB2bCveqcwOflO0FNFVZ6DRw/3CRT10SQ F7Fg== X-Gm-Message-State: AKS2vOydZ7YD1BcGRYLcFIgQBHmq6VrQcLJcetjb2yvJP/pnFgIoWvbG 7Z3/HlLl8KsORSl3rHE/eu6kI9iMrEnLnc81yryNr81DOiUDDyKmnIcy5Hiz9A7wyV16uRRFKxi O2HaQZt0= X-Received: by 10.99.167.15 with SMTP id d15mr17946116pgf.42.1498779811974; Thu, 29 Jun 2017 16:43:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Thu, 29 Jun 2017 16:43:01 -0700 (PDT) In-Reply-To: <149877955945.4706.12349304772344508035@ietfa.amsl.com> References: <149877955945.4706.12349304772344508035@ietfa.amsl.com> From: Brian Campbell Date: Thu, 29 Jun 2017 17:43:01 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a114c39dc4a28cd055321de65" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 23:43:35 -0000 --001a114c39dc4a28cd055321de65 Content-Type: text/plain; charset="UTF-8" This is a very minor revision containing a couple editorial fixes and an update to the title (to hopefully be less bad). ---------- Forwarded message ---------- From: Date: Thu, Jun 29, 2017 at 5:39 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-02.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-02.txt Pages : 13 Date : 2017-06-29 Abstract: This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for both OAuth client authentication to the token endpoint as well as for sender constrained access to OAuth protected resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-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/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a114c39dc4a28cd055321de65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a very minor revision containing a couple editoria= l fixes and an update to the title (to hopefully be less bad).

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu= , Jun 29, 2017 at 5:39 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oau= th-mtls-02.txt
To: i-d-announce= @ietf.org
Cc: oauth@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mutual TLS Profile for OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-29

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for bot= h OAuth
=C2=A0 =C2=A0client authentication to the token endpoint as well as for sen= der
=C2=A0 =C2=A0constrained access to OAuth protected resources.


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

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a114c39dc4a28cd055321de65-- From nobody Fri Jun 30 13:09:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0575D12E957 for ; Fri, 30 Jun 2017 13:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnXKokwDEIAq for ; Fri, 30 Jun 2017 13:08:57 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 332A4128BC8 for ; Fri, 30 Jun 2017 13:08:54 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id j186so68267704pge.2 for ; Fri, 30 Jun 2017 13:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zsb9WlSk330L/jCDD6RIp0/hXuUSGDt5ogNB5GYqMsg=; b=NZi9kC5FndJl3YN9DGaUdZHAcggUN78Z8JwC7m+6mOGGZXINahErhk3Sr8IZjf38QR 3fmujJaIgX85XDDVzuXlaRUkJi/uUfuZyLN8WIlGDbv6JqB+8U2PT3xFVSTSzFuSBdos 9Wai1ZkgRw56JcjbyjTtprF9R2IgA81U8N118= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zsb9WlSk330L/jCDD6RIp0/hXuUSGDt5ogNB5GYqMsg=; b=SJ55XqeGCLyM3HyQOJENT7q5YUBgZqaCspfMj4VHFGZlNEEwvo2xta4kXeB63nWLvu kadIa4q5j5oz2nooXZmu2ZMCAF2nKyKAXnbV6G6deQoGmKWWgwAn1Lybf47CdgZ/HdQg octaR3Q0yozf2iySHt0PEVu8+CAT3i9H0H8+n1kRP/BA1YqhhRRy4CSbHWEmqy3N6lqB LmOkObaK3n3Pt0pDGBMd7W3S7XJ4/g2ysV7BVdx7+jUAl58nzh6u+MFb9npZ2yJ0yRmB jAiY7kfA0J5qcu2iZ3DCbX8BL3/Dh5rH0GVGG97jZtdMfePLFLLcGJDeu0VkE58wPDwG tw5Q== X-Gm-Message-State: AKS2vOypEzmeHas9CVXLjiDgjyfeEs0Pa4ZRTfgmlJyqNWdHrHLyIMU9 Med5xTB0N0wgF79fRVrvrAKiNM4GZ2lSr9UBav1xXqUVsqXOkkqn137/4p1c+YlLMYmr53MmsA2 D0dDxt0U= X-Received: by 10.98.139.11 with SMTP id j11mr24594443pfe.18.1498853333683; Fri, 30 Jun 2017 13:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Fri, 30 Jun 2017 13:08:23 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 30 Jun 2017 14:08:23 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c14fd80867029055332fc90" Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 20:08:59 -0000 --94eb2c14fd80867029055332fc90 Content-Type: text/plain; charset="UTF-8" Thanks for the review, Rifaat. Replies are inline below... On Mon, Jun 26, 2017 at 6:40 AM, Rifaat Shekh-Yusef wrote: > Hi (as individual), > > I have reviewed this version of the document and I have the following > comments/questions: > > > Section 2.1, page 8, last paragraph: > > "In the absence of one-time-use or other semantics specific to the > token type, the act of performing a token exchange has no impact on > the validity of the subject token or actor token." > > Would the validity of the new issued token be impacted later on by the > validity of the subject or actor tokens? > No, the intent is that the tokens presented for exchange need to be valid at the time of exchange but after that the validity of the issued token is decoupled from, and has no dependency on, the subject or actor tokens. Do you feel that the doc should state this more explicitly? If so, a sentence like this could be added following the text you quoted, "Furthermore, the validity of the subject token or actor token have no impact on the validity of the issued token after the exchange has occurred." > Section 2.2.2, page 10, second paragraph: > > "If the authorization server is unwilling or unable to issue a token > for all the target services indicated by the "resource" or "audience" > parameters, the "invalid_target" error code MAY be used in the error > response." > > Can you please elaborate on why the above text is using "MAY" for the use > of "invalid_target" in this case? > > To be honest, I don't recall exactly why I went with "MAY" there. And on seeing your question and reading it again, that feels like it should be stronger than "MAY". Should that "MAY" be changed to a "SHOULD"? Or even a "MUST"? > Section 4.1, page 14, second paragraph: > > "However, claims within the "act" claim pertain only to the identity > of the actor and are not relevant to the validity of the containing > JWT in the same manner as the top-level claims. Consequently, claims > such as "exp", "nbf", and "aud" are not meaningful when used within > an "act" claim, and therefore should not be used." > > If the "exp", "nbf", and "aud" claims are not meaningful inside the "act" > claim, why is the sentence stating that it "should not be used"? > Would it not be more appropriate to state that it "must not be used" > instead? > > My thinking here is that saying, 'such as "exp", "nbf", and "aud" claims' is more of a general statement of guidance rather than a fully inclusive of list of claims that aren't meaningful inside the 'act' claim. And a full list isn't really feasible given that new claims can be defined in the future. So the use of "should" seemed more appropriate in that context rather than "must" or any RFC 2119 words. We can discuss changing that somehow, if you and/or other WG members think a change is needed? But that was my line of reasoning behind the current text. > > > Regards, > Rifaat > > > > > > On Fri, Jun 2, 2017 at 3:05 PM, Rifaat Shekh-Yusef > wrote: > >> All, >> >> We are starting a WGLC on the Token Exchange document: >> https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 >> >> Please, review the document and provide feedback on any issues you see >> with the document. >> >> The WGLC will end in two weeks, on June 17, 2017. >> >> Regards, >> Rifaat and Hannes >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c14fd80867029055332fc90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Rifaat. Replies are inline below...=


On M= on, Jun 26, 2017 at 6:40 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com= > wrote:
Hi (as individual),

I have = reviewed this version of the document and I have the following comments/que= stions:


Section 2.1, page 8, last p= aragraph:

=C2=A0 =C2=A0"In the absence of one= -time-use or other semantics specific to the
=C2=A0 =C2=A0 token = type, the act of performing a token exchange has no impact on
=C2= =A0 =C2=A0 the validity of the subject token or actor token."

Would the validity of the new issued token be impacted lat= er on by the validity of the subject or actor tokens?

No, the intent is that the tokens presented for exch= ange need to be valid at the time of exchange but after that the validity o= f the issued token is decoupled from, and has no dependency on, the subjec= t or actor tokens.

Do you feel that the doc should state = this more explicitly? If so, a sentence like this could be added following = the text you quoted, "Furthermore, the validity of the subject token o= r actor token have no impact on the validity of the issued token after the = exchange has occurred."

=C2=A0


Section 2.2.2, page 10, second paragraph:

=C2=A0 "If the authorization server is unwilling or unable to = issue a token
=C2=A0 =C2=A0for all the target services indicated = by the "resource" or "audience"
=C2=A0 =C2=A0= parameters, the "invalid_target" error code MAY be used in the er= ror
=C2=A0 =C2=A0response."

Can you= please elaborate on why the above text is using "MAY" for the us= e of "invalid_target" in this case?


To be honest, I don't recall exactly why = I went with "MAY" there. And on seeing your question and reading = it again, that feels like it should be stronger than "MAY".
<= br>
Should that "MAY" be changed to a "SHOULD"= ;? Or even a "MUST"?
=C2=A0



Section 4.1, page 14, second paragraph:

=C2= =A0 "However, claims within the "act" claim pertain only to = the identity
=C2=A0 =C2=A0of the actor and are not relevant to th= e validity of the containing
=C2=A0 =C2=A0JWT in the same manner = as the top-level claims.=C2=A0 Consequently, claims
=C2=A0 =C2=A0= such as "exp", "nbf", and "aud" are not meani= ngful when used within
=C2=A0 =C2=A0an "act" claim, and= therefore should not be used."

If the "= exp", "nbf", and "aud" claims are not meaningful i= nside the "act"
claim, why is the sentence stating that= it "should not be used"?
Would it not be more appropri= ate to state that it "must not be used" instead?


My thinking here is that saying,= 'such as "exp", "nbf", and "aud" claims&= #39; is more of a general statement of guidance rather than a fully inclusi= ve of list of claims that aren't meaningful inside the 'act' cl= aim. And a full list isn't really feasible given that new claims can be= defined in the future.=C2=A0 So the use of "should" seemed more = appropriate in that context rather than "must" or any RFC 2119 wo= rds. We can discuss changing that somehow, if you and/or other WG members t= hink a change is needed? But that was my line of reasoning behind the curre= nt text.


=C2=A0

=C2=A0
Regards,
=C2=A0Rifaat





On Fri, Jun 2, 2017 at= 3:05 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wro= te:
<= div>All,

We are starting a WGLC on the Token Excha= nge document:

Please, review the = document and provide feedback on any issues you see with the document.

The WGLC will end in two weeks, on June 17, 2017.

Regards,
=C2=A0Rifaat and Hannes
<= br>


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c14fd80867029055332fc90-- From nobody Fri Jun 30 14:35:46 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806D012EA97 for ; Fri, 30 Jun 2017 14:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlkXqBSPoEp9 for ; Fri, 30 Jun 2017 14:35:40 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 47E31129B75 for ; Fri, 30 Jun 2017 14:35:40 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id f127so69083942pgc.0 for ; Fri, 30 Jun 2017 14:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T3SK9qvQZlb3UN4bxtCY6YHkwkOVCQjS1C0olzyhgFg=; b=pLoqVVZQ/+ugNSC3l6aeGRb9Z73sw/G1JPAWSmOan1ssJHvcS6vpSnL3ghMFHe2Nhe 2otNv/KGkF7/f7nAt1tsmCKxV3BjJ09SpKhHrZOLswu/YU6ZSITJJToLl/lgLfwjPSns dcQo+3vuI+YQT3+oqsCAlwd76KNB1hj4MtCao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T3SK9qvQZlb3UN4bxtCY6YHkwkOVCQjS1C0olzyhgFg=; b=e5pMTrGW1gnJihbUFkK9lHC0RrgeLqYeHYJ9DTzDZm54ceqmQGCXxkVAvr7hDZnryz hvM7OISRJwffRr50bjYHR/Oy6FhgkvS10LTZ9RYM3jJNKFk3ahtwUKJfD68B5SxeuRon NuWXh1JfQKVE6lz87Ewdha25FqCDBYSUtjhukZT9ZyZyfIX1lHGAw0lesIi2OTEBw/u5 yDmMY1t2ocKsic1WAONz2gw3F6ODM38MRyWqpNHEeBcnMUKBXVa54XE/4sIYNw9C6QtK g/HyqT0HvLaujjrh27DpUIh95Wl9BqPlBzn7GmUUi0XnfUef7//EPcRqkmlpbiu2UwtU Yf/w== X-Gm-Message-State: AKS2vOzOKy8q4JW9G/7hQHRXT0JxSVdXDVDK8w2bGoyatlnRIwr+a+KN 7BWqMVzXM2co9S1wgEjZULmVb0qavwrsOLNnFc/5zrF3+Cn0k8V33pHfJwdRuA4twpGZLqmnIK4 R2NRpESo= X-Received: by 10.101.88.197 with SMTP id e5mr23076167pgu.144.1498858539659; Fri, 30 Jun 2017 14:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Fri, 30 Jun 2017 14:35:09 -0700 (PDT) In-Reply-To: <858f5a6a-f68c-c616-487a-a64cd8278755@free.fr> References: <858f5a6a-f68c-c616-487a-a64cd8278755@free.fr> From: Brian Campbell Date: Fri, 30 Jun 2017 15:35:09 -0600 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary="089e08234090d34b8d0553343282" Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:35:44 -0000 --089e08234090d34b8d0553343282 Content-Type: text/plain; charset="UTF-8" Thanks for the review, Denis. And I apologize for the slow reply - I've had a lot of different things on my plate recently. And, quite frankly, I was sort of hoping one of the co-authors on the document might respond to your comments. But hope only goes so far. So replies are inline below... On Mon, Jun 5, 2017 at 5:30 AM, Denis wrote: > Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08 > > 1. The abstract states: > > "This specification defines a protocol for an HTTP- and JSON- based > Security Token Service (STS) by defining how to request and obtain > security tokens from OAuth 2.0 authorization servers, including > security tokens employing impersonation and delegation". > > The problem is that the content of the abstract does not match with the > content of the document. > > The abstract clearly states that all cases of token requests are > supported, whereas the document mandates > the use of a subject_token parameter which restricts the scope to > impersonation and delegation. > > Currently the text states: > > "subject_token > *REQUIRED*. A security token that represents the identity of the > party on behalf of whom the request is being made. Typically, the > subject of this token will be the subject of the security token > issued in response to this request". > > The abstract should be changed to reflect the content of the document. > I don't see a discrepancy between the content of the abstract and the content of the document. What text or changes would you suggest in the abstract? > 2. The text states on page 4: > > "The scope of this specification is limited to the definition of a > basic request and response protocol for an STS-style token exchange > utilizing OAuth 2.0. Although a few new JWT claims are defined that > enable delegation semantics to be expressed, the specific syntax, > semantics and security characteristics of the tokens themselves (both > those presented to the AS and those obtained by the client) are > explicitly out of scope and no requirements are placed on the trust > model in which an implementation might be deployed". > > These statements are contradictory. One parameter of the request is > mandatory (i.e. subject_token) > but there is no indication of the kind of treatment which should be done > with this parameter so that > it will be taken into consideration one way or another in the token that > will be issued. > > This document by itself would be insufficient to allow any kind of > interoperability. > Conformance to this document would not mean anything. > The token exchange framework promotes interoperability in the form of common patterns and parameters that can be supported in libraries, products, and services. It facilitates deployments like this one https://help.salesforce.com/articleView?id=remoteaccess_oaut h_asset_token_flow.htm or this one https://developer.box.com/docs /getting-started-with-new-box-view, for example. > > 3. On page 7, the text states: > > "subject_token > REQUIRED. A security token that represents the identity of the > party on behalf of whom the request is being made". > > It is understood that one implementation is already using this parameter > to place in it a security token. > Since this parameter is indicated as REQUIRED, it is not understandable > why a security token shall necessarily be used. > There are other means for the STS to identify the "party on behalf of whom > the request is being made". > > Please add a rational. > I don't understand what kind of rational you are looking for here. Can you suggest some specific text for the document that would address the concern you have? > > In addition, what the STS will do, can do or should do with this parameter > is left undefined. > > > 4. On page 7, the text states: > > "subject_token > REQUIRED. (...) Typically, the subject of this token will be > the subject of the security token issued in response to this > request". > > This sentence is quite hard to understand since the specific syntax, > semantics and security characteristics of the tokens themselves > are explicitly out of scope. The key point is what the STS should do with > this parameter: this is left undefined. > I don't view the sentence as difficult to understand. Maybe that's because I wrote it? But it is true that typically it is the case that the subject of the inbound token will be the subject of the issued token. I don't know how else to say it. Please offer suggested text, if you believe there's a way to say it that is easier to understand. > > 5. The text states: > > " (...) Additional > profiles may provide more detailed requirements around the specific > nature of the parties and trust involved, such as whether signing > and/or encryption of tokens is needed or if proof-of-possession style > tokens will be required or issued; > > Tokens are always signed. Please modify the sentence accordingly. > A token might well be cryptographically secure random sequence of characters that reference data that can be looked up by the appropriate parties. Or a token might be an AEAD symmetrically encrypted JWT. So no, tokens are not always signed. > > > 6. The following sentence is important and is being noticed. > > The security tokens obtained could be used in a number of contexts, > the specifics of which are also beyond the scope of this > specification. > > Changing the "could" into a "may" would however be more appropriate. > Agreed, I'll make that change. > > > 7. In section 2.1 request, the text defines: > > resource > OPTIONAL. Indicates the physical location of the target service > or resource where the client intends to use the requested security > token. > > and > > audience > OPTIONAL. The logical name of the target service where the client > intends to use the requested security token. > > If the resource or the audience parameter is being used, the STS will have > the ability to know exactly which individual > or entity has accessed which target service and may keep a log of that > activity. It would be in a position to act as Big Brother. > This should be clearly indicated in a section that is currently missing : > "7. Privacy Considerations". See a text proposal hereafter. > > However, there is indeed the need to restrict the use of tokens to > specific targets. The key point is that the target service > must be able to recognize itself that the token is indeed targeted to it. > As an example, a challenge may be requested to > the target service and that challenge may then be placed into a specific > filed of the token. The target service may then verify > that the value included in the token is the one that has been recently > provided. > > A parameter specifying the type of the control value and the value of the > control should be added. > This parameter would be called a target_id (tid). It would solve the Big > Brother case. > That is both beyond the scope of this document and potentiality applicable to a broader context of use. I'd suggest you write an individual draft for the concept, if you want to pursue it. > > > 8. The Security Considerations section states: > > "In addition, both delegation and impersonation introduce unique > security issues. Any time one principal is delegated the rights of > another principal, the potential for abuse is a concern. The use of > the "scp" claim is suggested to mitigate potential for such abuse, as > it restricts the contexts in which the delegated rights can be > exercised". > > Section 4.2 defines the "scp" (Scopes) claim in the following way: > > The "scp" claim is an array of strings, each of which represents an > OAuth scope granted for the issued security token. Each array entry > of the claim value is a scope-token, as defined in Section 3.3 of > OAuth 2.0 [RFC6749]. > > Section 3.3 from RFC 6749 defines the Access Token Scope as: > > "The authorization and token endpoints allow the client to specify the > scope of the access request using the "scope" request parameter. In > turn, the authorization server uses the "scope" response parameter to > inform the client of the scope of the access token issued. > The value of the scope parameter is expressed as a list of space- > delimited, case-sensitive strings. The strings are defined by the > authorization server". > > Section 5.4.1 Registry Contents defines scp as: > > o Claim Name: "scp" > o Claim Description: Scope Values > o Change Controller: IESG > o Specification Document(s): Section 4.2 of [[ this specification ]] > > Since the "strings are defined by the authorization servers", what a scope > may mean is subject to multiple interpretations. > The current definition of scp is insufficient to allow any kind of > interoperability, now or in the future. > > It is thus unclear how the use of the "scp" claim might mitigate the risk. > Scoping the token restricts what the token can be used for which limits the impact of a compromised or misused token. The scope values are interpreted by the parties involved just as with regular OAuth. > > > 9. This document is currently targeted to become a Standards Track > document. > > RFC 6410 recognizes two maturity levels: > > - the First Maturity Level: Proposed Standard > - the Second Maturity Level: Internet Standard > > It is not believed that currently it is possible to construct two > independent interoperating implementations > looking at this document only. Unless more guidance is provided, this > document should be targeted to "Experimental". > I completely disagree. And would also note that the the document's intended status has been stable and unquestioned by this WG for several years. > > 10. Text proposal for a new section "7. Privacy Considerations". > > 7. Privacy Considerations > > 7.1. Resource and audience parameters > > The use of any these two parameters allow the STS to know which > target servers are being accessed by any party making a token > request. Any STS is then able to log token requests. This is not > a problem if the resource owner and the target server are collocated, > but this document is not restricted to that case. > > For the other cases, it should be noticed that the STS will be in > position to act as Big Brother. When privacy is a concern, the use > of these parameters is deprecated and the use of a "tid" parameter > is recommended. > > I will add a privacy considerations with mention of being able to track the target systems intended to be accessed by the party requesting a token. > > > > Denis > > All, > > We are starting a WGLC on the Token Exchange document: > https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 > > Please, review the document and provide feedback on any issues you see > with the document. > > The WGLC will end in two weeks, on June 17, 2017. > > Regards, > Rifaat and Hannes > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --089e08234090d34b8d0553343282 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Denis. And I apologize for the slow= reply - I've had a lot of different things on my plate recently. And, = quite frankly, I was sort of hoping one of the co-authors on the document m= ight respond to your comments. But hope only goes so far. So replies are in= line below...

= On Mon, Jun 5, 2017 at 5:30 AM, Denis <denis.ietf@free.fr> = wrote:
=20 =20 =20
Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08

1. The abstract states:
=C2=A0=C2=A0 "This specification defines a protocol = for an HTTP- and JSON- based
=C2=A0=C2=A0 Security Token Service (STS) by defining how to reques= t and obtain
=C2=A0=C2=A0 security tokens from OAuth 2.0 authorization servers, including
=C2=A0=C2=A0 security tokens employing impersonation and delegation= ".
The problem is that the content of the abstract does not match with the content of the document.

The abstract clearly states that all cases of token requests are supported, whereas the document mandates
the use of a subject_token parameter which restricts the scope to impersonation and delegation.

Currently the text states:

=C2=A0=C2=A0 "subject_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED.=C2=A0 A security toke= n that represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 party on behalf of whom the request is= being made.=C2=A0 Typically, the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 subject of this token will be the subj= ect of the security token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issued in response to this request&quo= t;.

The abstract should be changed to reflect the content of the document.

I don't= see a discrepancy between the content of the abstract and the content of t= he document.

What text or changes would you suggest in t= he abstract?
=C2=A0
=C2=A0

https://help.salesforce.com/articleView?id=3Dremot= eaccess_oauth_asset_token_flow.htm or this one https://developer.box.com/docs/getting-started-with-new-box-view= , for example.





3. On page 7, the text states:

=C2=A0=C2=A0 "subject_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED.=C2=A0 A security token that = represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 party on behalf of whom the request is= being made".

It is understood that one implementation is already using this parameter to place in it a security token.
Since this parameter is indicated as REQUIRED, it is not understandable why a security token shall necessarily be used.
There are other means for the STS to identify the "party on beha= lf of whom the request is being made".

Please add a rational.

I don't understand what kind of rational you are looking for here. Ca= n you suggest some specific text for the document that would address the co= ncern you have?

=C2=A0

In addition, what the STS will do, can do or should do with this parameter is left undefined.


4. On page 7, the text states:

=C2=A0=C2=A0 "subject_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED.=C2=A0 (...)=C2=A0 Typically,= the subject of this token will be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the subject of the security token issu= ed in response to this
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 request".

This sentence is quite hard to understand since the specific syntax, semantics and security characteristics of the tokens themselves
are explicitly out of scope. The key point is what the STS should do with this parameter: this is left undefined.

I don't view the sentence as difficult to un= derstand.=C2=A0 Maybe that's because I wrote it?=C2=A0 But it is true t= hat typically it is the case that the subject of the inbound token will be = the subject of the issued token. I don't know how else to say it. Pleas= e offer suggested text, if you believe there's a way to say it that is = easier to understand.
=C2=A0




5. The text states:
=C2=A0=C2=A0 " (...) Additional
=C2=A0=C2=A0 profiles may provide more detailed requirements around= the specific
=C2=A0=C2=A0 nature of the parties and trust involved, such as whet= her signing
=C2=A0=C2=A0 and/or encryption of tokens is needed or if proof-of-possession style
=C2=A0=C2=A0 tokens will be required or issued;
Tokens are always signed. Please modify the sentence accordingly.
=

A token might well be cryptogr= aphically secure random sequence of characters that reference data that can= be looked up by the appropriate parties. Or a token might be an AEAD symme= trically encrypted JWT. So no, tokens are not always signed.


=C2=A0


6. The following sentence is important and is being noticed.

=C2=A0=C2=A0 The security tokens obtained could be used in a number o= f contexts,
=C2=A0=C2=A0 the specifics of which are also beyond the scope of this=
=C2=A0=C2=A0 specification.

Changing the "could" into a "may" would however b= e more appropriate.

Agreed, = I'll make that change.
=C2=A0


7. In section=C2=A0 2.1 request, the text defines:

=C2=A0=C2=A0 resource
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Indicates the physical= location of the target service
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or resource where the client intends t= o use the requested security
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 token.=C2=A0

and

=C2=A0=C2=A0 audience
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 The logical name of th= e target service where the client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 intends to use the requested security = token.=C2=A0

If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual
or entity has accessed which target service and may keep a log of that activity. It would be in a position to act as Big Brother.
This should be clearly indicated in a section that is currently missing : "7. Privacy Considerations". See a text proposal hereafter.

However, there is indeed the need to restrict the use of tokens to specific targets. The key point is that the target service
must be able to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to
the target service and that challenge may then be placed into a specific filed of the token. The target service may then verify
that the value included in the token is the one that has been recently provided.

A parameter specifying the type of the control value and the value of the control should be added.
This parameter would be called a target_id (tid). It would solve the Big Brother case.

That is both beyond the scope of this document and potentiality applicable= to a broader context of use. I'd suggest you write an individual draft= for the concept, if you want to pursue it. =C2=A0

=C2= =A0


8. The Security Considerations section states:

=C2=A0=C2=A0 "In addition, both delegation and impersonation int= roduce unique
=C2=A0=C2=A0 security issues.=C2=A0 Any time one principal is delegat= ed the rights of
=C2=A0=C2=A0 another principal, the potential for abuse is a concern.= =C2=A0 The use of
=C2=A0=C2=A0 the "scp" claim is suggested to mitigate poten= tial for such abuse, as
=C2=A0=C2=A0 it restricts the contexts in which the delegated rights = can be
=C2=A0=C2=A0 exercised".

Section 4.2 defines the "scp" (Scopes) claim in the followi= ng way:

=C2=A0=C2=A0 The "scp" claim is an array of strings, each o= f which represents an
=C2=A0=C2=A0 OAuth scope granted for the issued security token.=C2=A0= Each array entry
=C2=A0=C2=A0 of the claim value is a scope-token, as defined in Secti= on 3.3 of
=C2=A0=C2=A0 OAuth 2.0 [RFC6749].

Section 3.3 from RFC 6749 defines the Access Token Scope as:

=C2=A0=C2=A0 "The authorization and token endpoints allow the cl= ient to specify the
=C2=A0=C2=A0 scope of the access request using the "scope" = request parameter.=C2=A0 In
=C2=A0=C2=A0 turn, the authorization server uses the "scope"= ; response parameter to
=C2=A0=C2=A0 inform the client of the scope of the access token issue= d.
=C2=A0=C2=A0 The value of the scope parameter is expressed as a list = of space-
=C2=A0=C2=A0 delimited, case-sensitive strings.=C2=A0 The strings are= defined by the
=C2=A0=C2=A0 authorization server".

Section 5.4.1 Registry Contents defines scp as:

=C2=A0=C2=A0 o=C2=A0 Claim Name: "scp"
=C2=A0=C2=A0 o=C2=A0 Claim Description: Scope Values
=C2=A0=C2=A0 o=C2=A0 Change Controller: IESG
=C2=A0=C2=A0 o=C2=A0 Specification Document(s): Section 4.2 of [[ thi= s specification ]]

Since the "strings are defined by the authorization servers"= ;, what a scope may mean is subject to multiple interpretations.
The current definition of scp is insufficient to allow any kind of interoperability, now or in the future.

It is thus unclear how the use of the "scp" claim might mit= igate the risk.

Scoping the= token restricts what the token can be used for which limits the impact of = a compromised or misused token. The scope values are interpreted by the par= ties involved just as with regular OAuth.

=C2=A0


9. This document is currently targeted to become a Standards Track document.

RFC 6410 recognizes two maturity levels:

=C2=A0=C2=A0 - the First Maturity Level: Proposed Standard
=C2=A0=C2=A0 - the Second Maturity Level: Internet Standard

It is not believed that currently it is possible to construct two independent interoperating implementations
looking at this document only. Unless more guidance is provided, this document should be targeted to "Experimental".

I completely disagree. And would a= lso note that the the document's intended status has been stable and un= questioned by this WG for several years.
=C2=A0



10. Text proposal for a new section "7. Privacy Considerations&q= uot;.

=C2=A0=C2=A0 7. Privacy Considerations

=C2=A0=C2=A0 7.1. Resource and audience parameters

=C2=A0=C2=A0 The use of any these two parameters allow the STS to kno= w which
=C2=A0=C2=A0 target servers are being accessed by any party making a = token
=C2=A0=C2=A0 request.=C2=A0 Any STS is then able to log token request= s.=C2=A0 This is not
=C2=A0=C2=A0 a problem if the resource owner and the target server ar= e collocated,
=C2=A0=C2=A0 but this document is not restricted to that case.

=C2=A0=C2=A0 For the other cases, it should be noticed that the STS w= ill be in
=C2=A0=C2=A0 position to act as Big Brother.=C2=A0 When privacy is a = concern, the use
=C2=A0=C2=A0 of these parameters is deprecated and the use of a "= ;tid" parameter
=C2=A0=C2=A0 is recommended.


I will add a privacy= considerations with mention of being able to track the target systems inte= nded to be accessed by the party requesting a token.
=C2=A0

=C2=A0


=C2=A0
Denis

All,

We are starting a WGLC on the Token Exchange document:

Please, review the document and provide feedback on any issues you see with the document.

The WGLC will end in two weeks, on June 17, 2017.

Regards,
=C2=A0Rifaat and 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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --089e08234090d34b8d0553343282-- From nobody Fri Jun 30 15:00:04 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D0912EABA for ; Fri, 30 Jun 2017 15:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo8kX7Wsom2N for ; Fri, 30 Jun 2017 15:00:00 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 DA38D129B95 for ; Fri, 30 Jun 2017 14:59:59 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id w19so62543975uac.0 for ; Fri, 30 Jun 2017 14:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+W5GcW2YeIVvQnO8yhBNCsazs09W/KIZOiqGrcUpTFg=; b=U+9yn6sG95WgsLtuQybiHY8VHhYZewRV1qCWOZHavUNwXeACmBRuVgm6eR842qy+p2 hxgyPwpsYOb4jd1k/N7Fb3YHwiNXin+YLGVhZ6VNEBR6UM+1g7tGCsG2GXrr+ewm4Yre wuxufrLFSZ66EN1MIg3Kwz16Zy/nFXu9cbmfJxyjH4ths8Tgdkf/AoLBhfQKjjOykl/s QIh8HpNjcKIfxY5nkhyba4DieCrmDf+g8qWZgYlHcYuRk3tSDViNaRWSLYuIZt3Yg+lc Um24V7Il1EG2NxZQ9gqFf7TQYdRYC/z7XRkpZYfOGLvANnWGdYUDkIeBOjkGk7tMyr3w 6HBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+W5GcW2YeIVvQnO8yhBNCsazs09W/KIZOiqGrcUpTFg=; b=N70wDk075MOrt/0jHDpQIqIGhZrNdbEYKZC040gL+XSQur2KUHSjApqeFsRiaqGaFJ db5VJNgrOY1pRGmetVuIhkIuO0kxLBe5uEd80o5g/NtTXqfVxUFkQS38usCrV4uWCaN1 8qQPXiwrlecIDE87yzxIsRXSJ6YocaJ/LYZS0Qf95FiIPmtU/3Os35gS0WQTSI/Bf5ph Cn0jgEwjkmTGmBP89xMwRut9nxufD8XkCiKy7cBVJZ1/V1iJaIVEp9EWfBrEhJs5UgGS tiXBretTb0xGM/aHdmsBsxSx8QeWZYrPrXeFYESLNFDpCBrgHlezoreJwwa4YqIb10cX e1Jg== X-Gm-Message-State: AKS2vOzooRlmq5Ir+hJqgpGr8r8IckNcJUZPzNYDPpKi6/QU/nPbflY0 h/r2MRNokq565fBl5IQAgd/97pBSTw== X-Received: by 10.176.24.172 with SMTP id t44mr14684860uag.16.1498859998985; Fri, 30 Jun 2017 14:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Fri, 30 Jun 2017 14:59:58 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Fri, 30 Jun 2017 17:59:58 -0400 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="f40304379b88cec64c05533489d5" Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 22:00:02 -0000 --f40304379b88cec64c05533489d5 Content-Type: text/plain; charset="UTF-8" Thanks Brian. See my replies inline... On Fri, Jun 30, 2017 at 4:08 PM, Brian Campbell wrote: > Thanks for the review, Rifaat. Replies are inline below... > > > On Mon, Jun 26, 2017 at 6:40 AM, Rifaat Shekh-Yusef > wrote: > >> Hi (as individual), >> >> I have reviewed this version of the document and I have the following >> comments/questions: >> >> >> Section 2.1, page 8, last paragraph: >> >> "In the absence of one-time-use or other semantics specific to the >> token type, the act of performing a token exchange has no impact on >> the validity of the subject token or actor token." >> >> Would the validity of the new issued token be impacted later on by the >> validity of the subject or actor tokens? >> > > No, the intent is that the tokens presented for exchange need to be valid > at the time of exchange but after that the validity of the issued token is > decoupled from, and has no dependency on, the subject or actor tokens. > > Do you feel that the doc should state this more explicitly? If so, a > sentence like this could be added following the text you quoted, > "Furthermore, the validity of the subject token or actor token have no > impact on the validity of the issued token after the exchange has > occurred." > > Yeah, your proposed text looks good to me. It is better to explicitly state that rather than leave it open to different interpretations. > > >> Section 2.2.2, page 10, second paragraph: >> >> "If the authorization server is unwilling or unable to issue a token >> for all the target services indicated by the "resource" or "audience" >> parameters, the "invalid_target" error code MAY be used in the error >> response." >> >> Can you please elaborate on why the above text is using "MAY" for the use >> of "invalid_target" in this case? >> >> > To be honest, I don't recall exactly why I went with "MAY" there. And on > seeing your question and reading it again, that feels like it should be > stronger than "MAY". > > Should that "MAY" be changed to a "SHOULD"? Or even a "MUST"? > > It seems to me that at least "SHOULD" is warranted here. Anybody has a strong opinion on this? > > > >> Section 4.1, page 14, second paragraph: >> >> "However, claims within the "act" claim pertain only to the identity >> of the actor and are not relevant to the validity of the containing >> JWT in the same manner as the top-level claims. Consequently, claims >> such as "exp", "nbf", and "aud" are not meaningful when used within >> an "act" claim, and therefore should not be used." >> >> If the "exp", "nbf", and "aud" claims are not meaningful inside the "act" >> claim, why is the sentence stating that it "should not be used"? >> Would it not be more appropriate to state that it "must not be used" >> instead? >> >> > My thinking here is that saying, 'such as "exp", "nbf", and "aud" claims' > is more of a general statement of guidance rather than a fully inclusive of > list of claims that aren't meaningful inside the 'act' claim. And a full > list isn't really feasible given that new claims can be defined in the > future. So the use of "should" seemed more appropriate in that context > rather than "must" or any RFC 2119 words. We can discuss changing that > somehow, if you and/or other WG members think a change is needed? But that > was my line of reasoning behind the current text. > > How about something along the line of the following to replace the last sentence above: "Consequently, non-identity claims (e.g. "exp", "nbf", and "aud") are not meaningful when used within an "act" claim, and therefore must not be used". Regards, Rifaat > > > >> >> >> > Regards, >> Rifaat >> >> >> >> >> >> On Fri, Jun 2, 2017 at 3:05 PM, Rifaat Shekh-Yusef > > wrote: >> >>> All, >>> >>> We are starting a WGLC on the Token Exchange document: >>> https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 >>> >>> Please, review the document and provide feedback on any issues you see >>> with the document. >>> >>> The WGLC will end in two weeks, on June 17, 2017. >>> >>> Regards, >>> Rifaat and Hannes >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --f40304379b88cec64c05533489d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Brian.

See my replies inline...<= /div>


On = Fri, Jun 30, 2017 at 4:08 PM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:
Thanks for the review, Rifaat. Replies are inline below...

=

On Mon= , Jun 26, 2017 at 6:40 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= div dir=3D"ltr">
Hi (as individual),

I have re= viewed this version of the document and I have the following comments/quest= ions:


Section 2.1, page 8, last par= agraph:

=C2=A0 =C2=A0"In the absence of one-t= ime-use or other semantics specific to the
=C2=A0 =C2=A0 token ty= pe, the act of performing a token exchange has no impact on
=C2= =A0 =C2=A0 the validity of the subject token or actor token."



<= /div>



=C2=A0

<= br>
Section 2.2.2, page 10, second paragraph:

=C2=A0 "If the authorization server is unwilling or unable to is= sue a token
=C2=A0 =C2=A0for all the target services indicated by= the "resource" or "audience"
=C2=A0 =C2=A0pa= rameters, the "invalid_target" error code MAY be used in the erro= r
=C2=A0 =C2=A0response."

Can you p= lease elaborate on why the above text is using "MAY" for the use = of "invalid_target" in this case?


To be honest, I don't recall exactly= why I went with "MAY" there. And on seeing your question and rea= ding it again, that feels like it should be stronger than "MAY". =

Should that "MAY" be changed to a "SHOULD= "? Or even a "MUST"?
=C2=A0

It seems to m= e that at least "SHOULD" is warranted here.=C2=A0
Anybo= dy has a strong opinion on this?

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">



Secti= on 4.1, page 14, second paragraph:

=C2=A0 "Ho= wever, claims within the "act" claim pertain only to the identity=
=C2=A0 =C2=A0of the actor and are not relevant to the validity o= f the containing
=C2=A0 =C2=A0JWT in the same manner as the top-l= evel claims.=C2=A0 Consequently, claims
=C2=A0 =C2=A0such as &quo= t;exp", "nbf", and "aud" are not meaningful when u= sed within
=C2=A0 =C2=A0an "act" claim, and therefore s= hould not be used."

If the "exp", &= quot;nbf", and "aud" claims are not meaningful inside the &q= uot;act"
claim, why is the sentence stating that it "sh= ould not be used"?
Would it not be more appropriate to state= that it "must not be used" instead?


My thinking here is that saying, '= ;such as "exp", "nbf", and "aud" claims' = is more of a general statement of guidance rather than a fully inclusive of= list of claims that aren't meaningful inside the 'act' claim. = And a full list isn't really feasible given that new claims can be defi= ned in the future.=C2=A0 So the use of "should" seemed more appro= priate in that context rather than "must" or any RFC 2119 words. = We can discuss changing that somehow, if you and/or other WG members think = a change is needed? But that was my line of reasoning behind the current te= xt.


= How about something along the line of the following to replace the last sen= tence above:

"Consequently, non-identity clai= ms (e.g. "exp", "nbf", and "aud") are not mea= ningful when used within an "act" claim, and therefore must not b= e used".

Regards,
=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0
Regards= ,
=C2=A0Rifaat



=


On Fri, Jun 2, 2017 at 3:05 PM,= Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,<= /div>

We are starting a WGLC on the Token Exchange docum= ent:

Please, review the document = and provide feedback on any issues you see with the document.
The WGLC will end in two weeks, on June 17, 2017.
Regards,
=C2=A0Rifaat and Hannes

=


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
<= /div> --f40304379b88cec64c05533489d5-- From nobody Fri Jun 30 15:18:42 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6D4128CFF for ; Fri, 30 Jun 2017 15:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rxiGjZUxiVA for ; Fri, 30 Jun 2017 15:18:38 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDC2127977 for ; Fri, 30 Jun 2017 15:18:37 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id g40so83467791uaa.3 for ; Fri, 30 Jun 2017 15:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+LdMV6DRUZWcZWjZjBFbltC6yeOB+ImbK73cdkN0qyo=; b=Asv+ON23tnKZjoLMSbZsY1hKZo1rEUCvBd9t0vfK+PRIsvf1Qat9HpTibduu0iP14+ Wv9k8JZyVRmKyKBkTuc1eA65hE5+T9LZ3lh/CQhZKmjmFrhg+ejauHb6X3KMvBHgGGih 8eZeUF3gj5IzRxr0osxYp7oIFvgBxEA5UopA9lnfW/+VV+cULxy69ZaX+gLT3iqlRFMT u8o6oLr6cz46SoQgqvshsbRIH9mKWS+Vp7gdpduvXzRrpV0x9n89JfKa1TavNfkBEG/X PO9r6ukmpLKZUCzQ+lei2zGmMzd7cH1rROBqSsaiLVacgKI7PPYaeRXnl+IZ5/EnLRyI C8SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+LdMV6DRUZWcZWjZjBFbltC6yeOB+ImbK73cdkN0qyo=; b=HtIqz94/Br7LQp3TXrxo2Vis3n3BVIbbLrIGPjckl1EbLM799d6fpZlg6v1ML+w7Pm SrOGBh3fcH5bnXpkHCebHxCV/xPjAjfK2AgaAzbb8y+5q0G3vxIro3DRevyzjyQAOZRS vFlrW4Wm7o1ohgUXDhfKOgzv7t0Ki9P1CZcXyfsVCVmohRhqO6Eyt5uIuHP06+73JYac Qu9YdZL/wK0RrlyX28XGGBA4MK5AVth9VeBGzhMsNOvMdY0UlY0v1qBk7vkK2e2RDEv4 p9u6hiAJr0Kb7Sy9FWSEfDmAYsHzHaKz8MwtlN0dkZV95z8maEKTbJ20u1zxWx8mECQr dftw== X-Gm-Message-State: AKS2vOwNNi6M0pmDLH03GI650h9KToOZdMzLXm5Q67zBRFvlGxevMIMx gYU55fmvWqFZmLtPsbTcdlB8g/Wm+g== X-Received: by 10.176.9.222 with SMTP id e30mr14742292uah.52.1498861117092; Fri, 30 Jun 2017 15:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Fri, 30 Jun 2017 15:18:36 -0700 (PDT) In-Reply-To: <8C46E20E-EFF4-481A-99E7-ADD1A9DF133F@mit.edu> References: <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu> <8C46E20E-EFF4-481A-99E7-ADD1A9DF133F@mit.edu> From: Rifaat Shekh-Yusef Date: Fri, 30 Jun 2017 18:18:36 -0400 Message-ID: To: Justin Richer Cc: "" Content-Type: multipart/alternative; boundary="f403043eea4873bade055334ccaf" Archived-At: Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 22:18:41 -0000 --f403043eea4873bade055334ccaf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 28, 2017 at 4:45 PM, Justin Richer wrote: > > On Jun 28, 2017, at 2:35 PM, Rifaat Shekh-Yusef > wrote: > > > On Wed, Jun 28, 2017 at 11:33 AM, Justin Richer wrote: > >> This is functionally equivalent to polling, as far as the spec is >> concerned. Instead of it being a timeout-based poll, it=E2=80=99s an >> interaction-based poll. Either way, the device makes a new HTTP request = to >> the AS to see if the device code is good or not, and either option is >> possible at that point as far as the device knows=E2=80=94 the user coul= d go mash >> buttons as fast as possible without ever entering the user code. >> >> > You are correct that this does not change the communication model, but if > there is a large number of devices being configured at the same time, the= n > the polling as it is defined in the document unnecessarily overloads the = AS > whether the user is doing anything or not. > > > The polling mechanism already has slow-down and other mechanisms to > prevent the AS from being unnecessarily overloaded by well-behaved client= s. > > Sure, but *if* there is a way to avoid the polling altogether, then we might not need these slow-down mechanisms in the first place. > >> In practice, this isn=E2=80=99t very likely to happen, as it requires ad= ditional >> steps for the user and >> > > It requires one more step (not steps), which is the user pushing the > button one more time after the user is done with authenticating and > authorizing the device; do you see any other steps needed here? > > > What you describe as =E2=80=9Cclicking the button=E2=80=9D really isn=E2= =80=99t that simple in the > real world: > > 1) Being told I need to go click a button by the AS, or maybe I need to g= o > click a button, because now we have something that=E2=80=99s device speci= fic and > would be tied to the device registration. After all, some things will be > =E2=80=9Cautomatic=E2=80=9D per the user=E2=80=99s experience (because of= polling) and some will > require further actions. > 2) Finding the device because I wasn=E2=80=99t at the device I was at my = computer > and maybe the device needs me to do something else or maybe not (see step= 1) > 3) Finding the button on the device, or is that one the power button? Or > does this one require me to wave my hand in front of a sensor instead of = a > button? Maybe there are some instructions on the device, or it will talk = to > me and tell me what to do when I push the button. > 4) Clicking the button. Or waving my hand. Or shaking it really hard. Or > licking it. > 5) Checking to see if it worked, maybe clicking the button again just in > case... > > We are talking about a use case where a person is getting ready to install a device, and you would expect the user to be able to find the device he wants to install and interact with that device. Are you expecting the user to be able to install a device without any interaction with that device? Regards, Rifaat > > > >> makes for a more clunky experience. >> > > I guess this is subjective, but why do you think it is clunky? > > > See the process above. It=E2=80=99s going to be incredibly device specifi= c and not > something we can, or should address at the protocol level, especially sin= ce > the protocol as-is already allows for action-based polling completely > transparently to the rest of the system. > > I don=E2=80=99t see any need for changes to the document to accommodate t= his. I > would not be against a very small note that polling could happen on a > reactive basis from the device instead of a timer, perhaps adding somethi= ng > like this sentence to =C2=A73.3=C2=B63: > > Common mechanisms for determining when to poll include use of an internal > timer and reliance on an interaction with the user, such as a button clic= k > or other physical activation. The details of such reactive polling behavi= or > are expected to be device specific and are therefore outside the scope of > this specification. > > > Thanks, > > =E2=80=94 Justin > > > > Regards,. > Rifaat > > > > >> If anything, we might see it as an optimization in some environments for >> some clients. In any event, it=E2=80=99s not any different from the spec= =E2=80=99s >> perspective. >> >> =E2=80=94 Justin >> >> On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef >> wrote: >> >> Hi (as individual), >> >> I have reviewed the Device Flow document, and I have a question about th= e >> polling part. >> The current draft is calling for the Device Client to poll the AS for a >> token (steps E & F of Figure 1). >> >> Presumably, the process started with the user pushing some button on the >> Device Client to initiate the process. >> One way to avoid the need for polling is for the Device Access Token >> Request to be sent to the AS only after the user for example pushed that >> same button again. >> This would allow the user to perform steps C and D to authorize the >> device, and then push the button again to get the token. >> >> Thoughts? >> >> Regards, >> Rifaat >> >> >> On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef > > wrote: >> >>> All, >>> >>> We are starting a WGLC on the Device Flow document: >>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 >>> >>> Please, review the document and provide feedback on any issues you see >>> with the document. >>> >>> The WGCL will end in two weeks, on June 16, 2017. >>> >>> Regards, >>> Rifaat and Hannes >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > --f403043eea4873bade055334ccaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 28, 2017 at 4:45 PM, Justin Richer <jricher@mit.edu><= /span> wrote:

On Jun 28= , 2017, at 2:35 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:


On Wed, Jun 28= , 2017 at 11:33 AM, Justin Richer <jricher@mit.edu> wrote:
=
This is functionally equivalent to polling, as far as the spec i= s concerned. Instead of it being a timeout-based poll, it=E2=80=99s an inte= raction-based poll. Either way, the device makes a new HTTP request to the = AS to see if the device code is good or not, and either option is possible = at that point as far as the device knows=E2=80=94 the user could go mash bu= ttons as fast as possible without ever entering the user code.


You are correct that this does not= change the communication model, but if there is a large number of devices = being configured at the same time, then the polling as it is defined in the= document unnecessarily overloads the AS whether the user is doing anything= or not.


=
The polling mechanism already has slow-down and other mec= hanisms to prevent the AS from being unnecessarily overloaded by well-behav= ed clients.=C2=A0


Sure, but if=C2=A0there is a way to avoid the p= olling altogether, then we might not need these slow-down mechanisms in the= first place.

=C2=A0
In practice, this isn=E2=80= =99t very likely to happen, as it requires additional steps for the user an= d

It requires one more step (n= ot steps), which is the user pushing the button one more time after the use= r is done with authenticating and authorizing the device; do you see any ot= her steps needed here?


What you describe as =E2=80=9Cclicking = the button=E2=80=9D really isn=E2=80=99t that simple in the real world:

1) Being told I need to go click a button by the AS, = or maybe I need to go click a button, because now we have something that=E2= =80=99s device specific and would be tied to the device registration. After= all, some things will be =E2=80=9Cautomatic=E2=80=9D per the user=E2=80=99= s experience (because of polling) and some will require further actions.
2) Finding the device because I wasn=E2=80=99t at the device I was = at my computer and maybe the device needs me to do something else or maybe = not (see step 1)
3) Finding the button on the device, or is that = one the power button? Or does this one require me to wave my hand in front = of a sensor instead of a button? Maybe there are some instructions on the d= evice, or it will talk to me and tell me what to do when I push the button.=
4) Clicking the button. Or waving my hand. Or shaking it really = hard. Or licking it.
5) Checking to see if it worked, maybe click= ing the button again just in case...

<= /span>

We are talking about a u= se case where a person is getting ready to install a device, and you would = expect the user to be able to find the device he wants to install and inter= act with that device.
Are you expecting the user to be able to in= stall a device without any interaction with that device?


Regards,
=C2=A0Rifaat
=C2=A0

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
makes for a more clunky experience.

I guess this is subjective, but why do you think it is= clunky?

See the process above. It=E2=80=99s going to be incredibly device sp= ecific and not something we can, or should address at the protocol level, e= specially since the protocol as-is already allows for action-based polling = completely transparently to the rest of the system.=C2=A0

I don=E2=80=99t see any need for changes to the document to accommo= date this. I would not be against a very small note that polling could happ= en on a reactive basis from the device instead of a timer, perhaps adding s= omething like this sentence to =C2=A73.3=C2=B63:

=
C= ommon mechanisms for determining when to poll include use of an internal ti= mer and reliance on an interaction with the user, such as a button click or= other physical activation. The details of such reactive polling behavior a= re expected to be device specific and are therefore outside the scope of th= is specification.=C2=A0

Th= anks,

=C2=A0=E2=80=94 Justin


=

R= egards,.
=C2=A0Rifaat


=C2= =A0
If anything, we might see it as an optimization in= some environments for some clients. In any event, it=E2=80=99s not any dif= ferent from the spec=E2=80=99s perspective.

=C2=A0= =E2=80=94 Justin

On Jun 28, 2017, at 8:27 AM, Rif= aat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

= Hi (as individual),

I have reviewed the Device Flo= w document, and I have a question about the polling part.
The cur= rent draft is calling for the Device Client to poll the AS for a token (ste= ps E & F of Figure 1).

Presumably, the process= started with the user pushing some button on the Device Client to initiate= the process.
One way to avoid the need for polling is for the De= vice Access Token Request to be sent to the AS only after the user for exam= ple pushed that same button again.
This would allow the user to p= erform steps C and D to authorize the device, and then push the button agai= n to get the token.

Thoughts?

=
Regards,
=C2=A0Rifaat


On Thu, Jun 1, 2017 at 8:32= AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,
We are starting a WGLC on the Device Flow document:
=

Please, review the document and = provide feedback on any issues you see with the document.

The WGCL will end in two weeks, on June 16, 2017.
Regards,
=C2=A0Rifaat and Hannes

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




--f403043eea4873bade055334ccaf-- From nobody Fri Jun 30 15:52:52 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2721A12EAE4 for ; Fri, 30 Jun 2017 15:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hpb28Lx47aG for ; Fri, 30 Jun 2017 15:52:34 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 4B6A5129B95 for ; Fri, 30 Jun 2017 15:52:34 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id u62so69673772pgb.3 for ; Fri, 30 Jun 2017 15:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G6TOrlU4j05285EwbRr3eg0lwaHCprhqEeIx22ProqA=; b=F2Vvp4d/BDysK8sHyMF6rrjkUFmJG2ZnTPgqZg0d0WkmjWWOGLj81m+YNqdtxs37Ut Jbt1BWvf2w73Sv4SNW57f4DE0FTs4QJhkrgcnWnpwUGeMgf8icuKlYqLIvzqhWgp4G/F tM/DNJwIZDSraGb+q4edigY7Dv6vong5xXKFo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G6TOrlU4j05285EwbRr3eg0lwaHCprhqEeIx22ProqA=; b=T2KN9a/NaCu9/75P90UtAR790OLMC/rQ8K9laoI7somsY0Ejvun2Y7YONrcW0QgKL4 SbpL2AKSTbWZlnpT1WyJfLpawjG/m3+wmAm0sQaH1Kn2U5aEFCu1FF/USfCyORm1m5W8 Yqn0yGE601hCl9OpDbMzzBWX+IIprP9znG615sFs0a4pdHFYGM9aYhmvuqV29VnvXLC9 +zWHQRPPiyM4bk2yQsUI/AqiY9KhOqgODnJ9dEaEKDEbFtlxbNKrHQB/wByzDkrA8PtT eCq4YUWW25QwR71kWlGBAGMhP0Un1Xj6YBazhsnrVQv7AWQ9t7C5GHpgpRPbfu8s6WFi B08g== X-Gm-Message-State: AKS2vOz0ZpoRtjloQyu3AL90NTLTSz5eVsJTKYdda1RoWVf806DZrzvU QKv3a4PumefnvJfWiwB4WeWvbaYadw6itiQogOG2wR6CkNrmjgNPvI97S4oBUyzdI++pbm9d1wo mCKuy X-Received: by 10.101.88.197 with SMTP id e5mr23330134pgu.144.1498863153861; Fri, 30 Jun 2017 15:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Fri, 30 Jun 2017 15:52:32 -0700 (PDT) Received: by 10.100.129.130 with HTTP; Fri, 30 Jun 2017 15:52:32 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 30 Jun 2017 16:52:32 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="089e08234090da75f50553354518" Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 22:52:44 -0000 --089e08234090da75f50553354518 Content-Type: text/plain; charset="UTF-8" Okay, thanks Rifaat. I'll make those changes. On Jun 30, 2017 3:59 PM, "Rifaat Shekh-Yusef" wrote: > Thanks Brian. > > See my replies inline... > > > On Fri, Jun 30, 2017 at 4:08 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Thanks for the review, Rifaat. Replies are inline below... >> >> >> On Mon, Jun 26, 2017 at 6:40 AM, Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com> wrote: >> >>> Hi (as individual), >>> >>> I have reviewed this version of the document and I have the following >>> comments/questions: >>> >>> >>> Section 2.1, page 8, last paragraph: >>> >>> "In the absence of one-time-use or other semantics specific to the >>> token type, the act of performing a token exchange has no impact on >>> the validity of the subject token or actor token." >>> >>> Would the validity of the new issued token be impacted later on by the >>> validity of the subject or actor tokens? >>> >> >> No, the intent is that the tokens presented for exchange need to be valid >> at the time of exchange but after that the validity of the issued token is >> decoupled from, and has no dependency on, the subject or actor tokens. >> >> Do you feel that the doc should state this more explicitly? If so, a >> sentence like this could be added following the text you quoted, >> "Furthermore, the validity of the subject token or actor token have no >> impact on the validity of the issued token after the exchange has >> occurred." >> >> > Yeah, your proposed text looks good to me. It is better to explicitly > state that rather than leave it open to different interpretations. > > > >> >> >>> Section 2.2.2, page 10, second paragraph: >>> >>> "If the authorization server is unwilling or unable to issue a token >>> for all the target services indicated by the "resource" or "audience" >>> parameters, the "invalid_target" error code MAY be used in the error >>> response." >>> >>> Can you please elaborate on why the above text is using "MAY" for the >>> use of "invalid_target" in this case? >>> >>> >> To be honest, I don't recall exactly why I went with "MAY" there. And on >> seeing your question and reading it again, that feels like it should be >> stronger than "MAY". >> >> Should that "MAY" be changed to a "SHOULD"? Or even a "MUST"? >> >> > > It seems to me that at least "SHOULD" is warranted here. > Anybody has a strong opinion on this? > > > >> >> >> >>> Section 4.1, page 14, second paragraph: >>> >>> "However, claims within the "act" claim pertain only to the identity >>> of the actor and are not relevant to the validity of the containing >>> JWT in the same manner as the top-level claims. Consequently, claims >>> such as "exp", "nbf", and "aud" are not meaningful when used within >>> an "act" claim, and therefore should not be used." >>> >>> If the "exp", "nbf", and "aud" claims are not meaningful inside the "act" >>> claim, why is the sentence stating that it "should not be used"? >>> Would it not be more appropriate to state that it "must not be used" >>> instead? >>> >>> >> My thinking here is that saying, 'such as "exp", "nbf", and "aud" claims' >> is more of a general statement of guidance rather than a fully inclusive of >> list of claims that aren't meaningful inside the 'act' claim. And a full >> list isn't really feasible given that new claims can be defined in the >> future. So the use of "should" seemed more appropriate in that context >> rather than "must" or any RFC 2119 words. We can discuss changing that >> somehow, if you and/or other WG members think a change is needed? But that >> was my line of reasoning behind the current text. >> >> > How about something along the line of the following to replace the last > sentence above: > > "Consequently, non-identity claims (e.g. "exp", "nbf", and "aud") are not > meaningful when used within an "act" claim, and therefore must not be used". > > Regards, > Rifaat > > > >> >> >> >>> >>> >>> >> Regards, >>> Rifaat >>> >>> >>> >>> >>> >>> On Fri, Jun 2, 2017 at 3:05 PM, Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>>> All, >>>> >>>> We are starting a WGLC on the Token Exchange document: >>>> https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 >>>> >>>> Please, review the document and provide feedback on any issues you see >>>> with the document. >>>> >>>> The WGLC will end in two weeks, on June 17, 2017. >>>> >>>> Regards, >>>> Rifaat and Hannes >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* > > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --089e08234090da75f50553354518 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, thanks Rifaat. I'll make those changes.

On Jun 30, 2017 3:5= 9 PM, "Rifaat Shekh-Yusef" <rifaat.ietf@gmail.com> wrote:
Thanks Brian.

S= ee my replies inline...


On Fri, Jun 30, 2017 at 4:08 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Thanks for the review, Rifaat. Replies are i= nline below...


On Mon, Jun 26, 2017 at 6:40 AM, Rifaat Shekh-Yusef <r= ifaat.ietf@gmail.com> wrote:
Hi (as individual),
I have reviewed this version of the document and I have the fo= llowing comments/questions:


Section= 2.1, page 8, last paragraph:

=C2=A0 =C2=A0"I= n the absence of one-time-use or other semantics specific to the
= =C2=A0 =C2=A0 token type, the act of performing a token exchange has no imp= act on
=C2=A0 =C2=A0 the validity of the subject token or actor t= oken."

Would the validity of the new issued t= oken be impacted later on by the validity of the subject or actor tokens?

No, the intent is that th= e tokens presented for exchange need to be valid at the time of exchange bu= t after that the validity of the issued token is decoupled from, and has n= o dependency on, the subject or actor tokens.

Do you feel= that the doc should state this more explicitly? If so, a sentence like thi= s could be added following the text you quoted, "Furthermore, the vali= dity of the subject token or actor token have no impact on the validity of = the issued token after the exchange has occurred."


Yeah, your proposed text looks good to me. It is better to explicitly stat= e that rather than leave it open to different interpretations.

=C2=A0


Section 2.2.2, page 10, second paragraph:=

=C2=A0 "If the authorization server is unwil= ling or unable to issue a token
=C2=A0 =C2=A0for all the target s= ervices indicated by the "resource" or "audience"
=
=C2=A0 =C2=A0parameters, the "invalid_target" error code MAY= be used in the error
=C2=A0 =C2=A0response."

=
Can you please elaborate on why the above text is using "MA= Y" for the use of "invalid_target" in this case?
<= br>

To be honest, I don&= #39;t recall exactly why I went with "MAY" there. And on seeing y= our question and reading it again, that feels like it should be stronger th= an "MAY".

Should that "MAY" be chang= ed to a "SHOULD"? Or even a "MUST"?
=C2=A0

It seems to me that at least "SHOULD" is warranted here.= =C2=A0
Anybody has a strong opinion on this?

=
=C2=A0
<= div class=3D"gmail_extra">


=
Section 4.1, page 14, second paragraph:

=
=C2=A0 "However, claims within the "act" claim pertain = only to the identity
=C2=A0 =C2=A0of the actor and are not releva= nt to the validity of the containing
=C2=A0 =C2=A0JWT in the same= manner as the top-level claims.=C2=A0 Consequently, claims
=C2= =A0 =C2=A0such as "exp", "nbf", and "aud" are= not meaningful when used within
=C2=A0 =C2=A0an "act" = claim, and therefore should not be used."

If = the "exp", "nbf", and "aud" claims are not me= aningful inside the "act"
claim, why is the sentence st= ating that it "should not be used"?
Would it not be mor= e appropriate to state that it "must not be used" instead?
<= div>

My thinking her= e is that saying, 'such as "exp", "nbf", and "= aud" claims' is more of a general statement of guidance rather tha= n a fully inclusive of list of claims that aren't meaningful inside the= 'act' claim. And a full list isn't really feasible given that = new claims can be defined in the future.=C2=A0 So the use of "should&q= uot; seemed more appropriate in that context rather than "must" o= r any RFC 2119 words. We can discuss changing that somehow, if you and/or o= ther WG members think a change is needed? But that was my line of reasoning= behind the current text.


How about something along the line of the following t= o replace the last sentence above:

"Consequen= tly, non-identity claims (e.g. "exp", "nbf", and "= aud") are not meaningful when used within an "act" claim, an= d therefore must not be used".

Regards,
=
=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0
<= div>
Regards,
=C2=A0Rifaat




On Fri, Jun 2, 2017 at 3:05 PM, Rifaat She= kh-Yusef <rifaat.ietf@gmail.com> wrote:
All,
<= br>
We are starting a WGLC on the Token Exchange document:
<= div>https://www.ietf.org/id/draft-ietf-oauth-token-excha= nge-08

Please, review the document and provide= feedback on any issues you see with the document.

The WGLC will end in two weeks, on June 17, 2017.

Regards,
=C2=A0Rifaat and Hannes



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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
<= /div>
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --089e08234090da75f50553354518-- From nobody Fri Jun 30 17:37:39 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755B312EB0E for ; Fri, 30 Jun 2017 17:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ulr3hPoLCu_d for ; Fri, 30 Jun 2017 17:37:34 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EC012EA5A for ; Fri, 30 Jun 2017 17:37:33 -0700 (PDT) X-AuditID: 1209190e-e5fff700000007cc-29-5956eecba09e 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 9B.95.01996.BCEE6595; Fri, 30 Jun 2017 20:37:31 -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 v610bUEY007945; Fri, 30 Jun 2017 20:37:31 -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 v610bSJb011746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Jun 2017 20:37:30 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_94E85D85-8553-4DDF-BE86-902192A03854" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 30 Jun 2017 20:37:28 -0400 In-Reply-To: Cc: "" To: Rifaat Shekh-Yusef References: <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu> <8C46E20E-EFF4-481A-99E7-ADD1A9DF133F@mit.edu> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixG6nrnv6XVikwfN/JhYn375is9j5opXN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MqYtvsJW8H/C4wVz+d8Ympg3L2JsYuRk0NC wERi4ZkrrF2MXBxCAouZJDZ/vcgKkhAS2MgoseFVBkTiIZPE61VdYAk2AVWJ6WtamEBsXgEr if9fLoFNYhZIknj46QlQDQdQXF+i9zlYWFjARmLJ351gNgtQ644/s8HGcAoESsy9dBysnFlA XaL9pAtIWERAT6L970ImiLXtzBKXfkxkhzhUVuLW7EvMExj5ZyHZNgthG0RYW2LZwtfMELam xP7u5SyY4hoSnd8msi5gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6yXm1mil5pSuokRFNic knw7GCc1eB9iFOBgVOLh3RASFinEmlhWXJl7iFGSg0lJlHfltdBIIb6k/JTKjMTijPii0pzU 4kOMEhzMSiK8z94ClfOmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIyHBxKEryM wAgWEixKTU+tSMvMKUFIM3FwggznARo+5QzI8OKCxNzizHSI/ClGY45NM35+Y+J4NeH/NyYh lrz8vFQpcd51b4BKBUBKM0rz4KaBklPC28OmrxjFgZ4T5u0BuZYHmNjg5r0CWsUEtEp4RgjI qpJEhJRUA+PCJYE/w7oqvu6rKhMMitjC8NHqIu+Tu2JHXnyP62kNvtelOt2WRfjNvCurCzr0 eA+/uGOzuqfIRLVEq+6ynMvm4otqPf8M/rzZu7Jt/7Qdc5wXKjUvWDbHVerowTkb/dk8Mr/9 bJv/fYE6r+2CawueFExuOj+lJnf745VFaY0vOpbpMsQeP/9EiaU4I9FQi7moOBEACoysPSkD AAA= Archived-At: Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 00:37:37 -0000 --Apple-Mail=_94E85D85-8553-4DDF-BE86-902192A03854 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline. > On Jun 30, 2017, at 6:18 PM, Rifaat Shekh-Yusef = wrote: >=20 > On Wed, Jun 28, 2017 at 4:45 PM, Justin Richer > wrote: >=20 >> On Jun 28, 2017, at 2:35 PM, Rifaat Shekh-Yusef = > wrote: >>=20 >>=20 >> On Wed, Jun 28, 2017 at 11:33 AM, Justin Richer > wrote: >> This is functionally equivalent to polling, as far as the spec is = concerned. Instead of it being a timeout-based poll, it=E2=80=99s an = interaction-based poll. Either way, the device makes a new HTTP request = to the AS to see if the device code is good or not, and either option is = possible at that point as far as the device knows=E2=80=94 the user = could go mash buttons as fast as possible without ever entering the user = code. >>=20 >>=20 >> You are correct that this does not change the communication model, = but if there is a large number of devices being configured at the same = time, then the polling as it is defined in the document unnecessarily = overloads the AS whether the user is doing anything or not. >>=20 >=20 > The polling mechanism already has slow-down and other mechanisms to = prevent the AS from being unnecessarily overloaded by well-behaved = clients.=20 >=20 >=20 > Sure, but if there is a way to avoid the polling altogether, then we = might not need these slow-down mechanisms in the first place. There=E2=80=99s not a way to avoid it altogether, and again I remind you = that the current spec will already fully allow the use case that = you=E2=80=99re describing, without requiring any changes to the text = whatsoever. You could literally build a client today that does exactly = what you=E2=80=99re talking about. All you need to do is: 1. Call the device code endpoint to get your device code and user code 2. Not call the token endpoint automatically 3. Wait until a button press to call the token endpoint 4. If you get a token back, great; if you get one of the errors back, = wait until another button press Note that if the user hammers the button too fast you should still wait = for the timeout before calling again. This is only slightly different = from most code deployed today: 1. Call the device code endpoint to get your device code and user code 2. Wait until a a timeout to call the token endpoint 3. If you get a token back, great; if you get one of the errors back, = wait until another timeout In fact, I wouldn=E2=80=99t at all be surprised that somebody=E2=80=99s = built the first one along with the number of implementations of the = second one that have been built to date. So I=E2=80=99m still not seeing = what changes you=E2=80=99d want in the specification to address this.=20 >=20 >> =20 >> In practice, this isn=E2=80=99t very likely to happen, as it requires = additional steps for the user and >>=20 >> It requires one more step (not steps), which is the user pushing the = button one more time after the user is done with authenticating and = authorizing the device; do you see any other steps needed here? >>=20 >=20 > What you describe as =E2=80=9Cclicking the button=E2=80=9D really = isn=E2=80=99t that simple in the real world: >=20 > 1) Being told I need to go click a button by the AS, or maybe I need = to go click a button, because now we have something that=E2=80=99s = device specific and would be tied to the device registration. After all, = some things will be =E2=80=9Cautomatic=E2=80=9D per the user=E2=80=99s = experience (because of polling) and some will require further actions. > 2) Finding the device because I wasn=E2=80=99t at the device I was at = my computer and maybe the device needs me to do something else or maybe = not (see step 1) > 3) Finding the button on the device, or is that one the power button? = Or does this one require me to wave my hand in front of a sensor instead = of a button? Maybe there are some instructions on the device, or it will = talk to me and tell me what to do when I push the button. > 4) Clicking the button. Or waving my hand. Or shaking it really hard. = Or licking it. > 5) Checking to see if it worked, maybe clicking the button again just = in case... >=20 >=20 > We are talking about a use case where a person is getting ready to = install a device, and you would expect the user to be able to find the = device he wants to install and interact with that device. That=E2=80=99s making a lot of assumptions about the nature of the = device and the availability of the non-constrained login platform.=20 > Are you expecting the user to be able to install a device without any = interaction with that device? >=20 If you=E2=80=99re provisioning thousands of devices simultaneously like = you said in your original email, I should hope I don=E2=80=99t need to = go around pushing a bunch of buttons to make it happen. So, yes. Perhaps if you can describe in detail what changes you=E2=80=99d like to = see to the specification, or in what way the current text does not allow = for your use case, then I=E2=80=99d be able to understand what you=E2=80=99= re asking for.=20 =E2=80=94 Justin >=20 > Regards, > Rifaat > =20 >=20 >> =20 >> makes for a more clunky experience. >>=20 >> I guess this is subjective, but why do you think it is clunky? >=20 > See the process above. It=E2=80=99s going to be incredibly device = specific and not something we can, or should address at the protocol = level, especially since the protocol as-is already allows for = action-based polling completely transparently to the rest of the system.=20= >=20 > I don=E2=80=99t see any need for changes to the document to = accommodate this. I would not be against a very small note that polling = could happen on a reactive basis from the device instead of a timer, = perhaps adding something like this sentence to =C2=A73.3=C2=B63: >=20 > Common mechanisms for determining when to poll include use of an = internal timer and reliance on an interaction with the user, such as a = button click or other physical activation. The details of such reactive = polling behavior are expected to be device specific and are therefore = outside the scope of this specification.=20 >=20 > Thanks, >=20 > =E2=80=94 Justin >=20 >=20 >>=20 >> Regards,. >> Rifaat >>=20 >>=20 >> =20 >> If anything, we might see it as an optimization in some environments = for some clients. In any event, it=E2=80=99s not any different from the = spec=E2=80=99s perspective. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef = > wrote: >>>=20 >>> Hi (as individual), >>>=20 >>> I have reviewed the Device Flow document, and I have a question = about the polling part. >>> The current draft is calling for the Device Client to poll the AS = for a token (steps E & F of Figure 1). >>>=20 >>> Presumably, the process started with the user pushing some button on = the Device Client to initiate the process. >>> One way to avoid the need for polling is for the Device Access Token = Request to be sent to the AS only after the user for example pushed that = same button again. >>> This would allow the user to perform steps C and D to authorize the = device, and then push the button again to get the token. >>>=20 >>> Thoughts? >>>=20 >>> Regards, >>> Rifaat >>>=20 >>>=20 >>> On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef = > wrote: >>> All, >>>=20 >>> We are starting a WGLC on the Device Flow document: >>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 = >>>=20 >>> Please, review the document and provide feedback on any issues you = see with the document. >>>=20 >>> The WGCL will end in two weeks, on June 16, 2017. >>>=20 >>> Regards, >>> Rifaat and Hannes >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_94E85D85-8553-4DDF-BE86-902192A03854 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline.

On Jun 30, 2017, at 6:18 PM, = Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

On Wed, Jun 28, 2017 = at 4:45 PM, Justin Richer <jricher@mit.edu> wrote:

On Jun 28, 2017, at 2:35 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:


On Wed, Jun 28, 2017 at 11:33 AM, = Justin Richer <jricher@mit.edu> wrote:
This is functionally = equivalent to polling, as far as the spec is concerned. Instead of it = being a timeout-based poll, it=E2=80=99s an interaction-based poll. = Either way, the device makes a new HTTP request to the AS to see if the = device code is good or not, and either option is possible at that point = as far as the device knows=E2=80=94 the user could go mash buttons as = fast as possible without ever entering the user code.


You are correct that this does not = change the communication model, but if there is a large number of = devices being configured at the same time, then the polling as it is = defined in the document unnecessarily overloads the AS whether the user = is doing anything or not.


The polling mechanism already = has slow-down and other mechanisms to prevent the AS from being = unnecessarily overloaded by well-behaved clients. 


Sure, but if there is a way to avoid the polling altogether, = then we might not need these slow-down mechanisms in the first = place.

There=E2=80=99s not a way to avoid it altogether, = and again I remind you that the current spec will already fully allow = the use case that you=E2=80=99re describing, without requiring any = changes to the text whatsoever. You could literally build a client today = that does exactly what you=E2=80=99re talking about. All you need to do = is:

1. Call the device code endpoint = to get your device code and user code
2. Not call the token = endpoint automatically
3. Wait until a button press to call = the token endpoint
4. If you get a token back, great; if you = get one of the errors back, wait until another button = press

Note that if the user hammers = the button too fast you should still wait for the timeout before calling = again. This is only slightly different from most code deployed = today:

1. Call the device code = endpoint to get your device code and user code
2. Wait until a = a timeout to call the token endpoint
3. If you get a token = back, great; if you get one of the errors back, wait until another = timeout

In fact, I wouldn=E2=80=99= t at all be surprised that somebody=E2=80=99s built the first one along = with the number of implementations of the second one that have been = built to date. So I=E2=80=99m still not seeing what changes you=E2=80=99d = want in the specification to address this. 


 
In = practice, this isn=E2=80=99t very likely to happen, as it requires = additional steps for the user and

It requires one more = step (not steps), which is the user pushing the button one more time = after the user is done with authenticating and authorizing the device; = do you see any other steps needed here?


What you describe = as =E2=80=9Cclicking the button=E2=80=9D really isn=E2=80=99t that = simple in the real world:

1) Being told I need to go click a button by the AS, or maybe = I need to go click a button, because now we have something that=E2=80=99s = device specific and would be tied to the device registration. After all, = some things will be =E2=80=9Cautomatic=E2=80=9D per the user=E2=80=99s = experience (because of polling) and some will require further = actions.
2) Finding the device because I wasn=E2=80=99= t at the device I was at my computer and maybe the device needs me to do = something else or maybe not (see step 1)
3) Finding = the button on the device, or is that one the power button? Or does this = one require me to wave my hand in front of a sensor instead of a button? = Maybe there are some instructions on the device, or it will talk to me = and tell me what to do when I push the button.
4) = Clicking the button. Or waving my hand. Or shaking it really hard. Or = licking it.
5) Checking to see if it worked, maybe = clicking the button again just in case...


We are talking about a = use case where a person is getting ready to install a device, and you = would expect the user to be able to find the device he wants to install = and interact with that device.

That=E2=80=99s making a lot of assumptions about = the nature of the device and the availability of the non-constrained = login platform. 

Are you expecting the user to be able to install a device = without any interaction with that device?


If you=E2=80=99re provisioning thousands of = devices simultaneously like you said in your original email, I should = hope I don=E2=80=99t need to go around pushing a bunch of buttons to = make it happen. So, yes.


Perhaps if you can describe in detail what changes = you=E2=80=99d like to see to the specification, or in what way the = current text does not allow for your use case, then I=E2=80=99d be able = to understand what you=E2=80=99re asking for. 


 =E2=80=94 = Justin


Regards,
 Rifaat
 

 
makes for a more clunky = experience.

I guess this is subjective, but why do = you think it is clunky?

See the process above. It=E2=80=99= s going to be incredibly device specific and not something we can, or = should address at the protocol level, especially since the protocol = as-is already allows for action-based polling completely transparently = to the rest of the system. 

I don=E2=80=99t see any need for = changes to the document to accommodate this. I would not be against a = very small note that polling could happen on a reactive basis from the = device instead of a timer, perhaps adding something like this sentence = to =C2=A73.3=C2=B63:

Common mechanisms for determining when to poll include use of = an internal timer and reliance on an interaction with the user, such as = a button click or other physical activation. The details of such = reactive polling behavior are expected to be device specific and are = therefore outside the scope of this = specification. 

Thanks,

 =E2=80=94 = Justin



Regards,.
 Rifaat


 
If anything, = we might see it as an optimization in some environments for some = clients. In any event, it=E2=80=99s not any different from the spec=E2=80=99= s perspective.

 =E2=80=94 Justin

On Jun 28, = 2017, at 8:27 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hi (as individual),

I have reviewed the Device Flow = document, and I have a question about the polling part.
The current draft is calling for the Device Client to poll = the AS for a token (steps E & F of Figure 1).
Presumably, the process started with = the user pushing some button on the Device Client to initiate the = process.
One way to avoid the need for polling is = for the Device Access Token Request to be sent to the AS only after the = user for example pushed that same button again.
This = would allow the user to perform steps C and D to authorize the device, = and then push the button again to get the token.

Thoughts?

Regards,
 Rifaat


On Thu, Jun 1, 2017 at 8:32 AM, Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

We are starting a WGLC on the Device Flow document:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06

Please, review the = document and provide feedback on any issues you see with the = document.

The = WGCL will end in two weeks, on June 16, 2017.

Regards,
 Rifaat and Hannes

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

= --Apple-Mail=_94E85D85-8553-4DDF-BE86-902192A03854-- From nobody Fri Jun 30 17:42:53 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285A212EB0F for ; Fri, 30 Jun 2017 17:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMJ94I_xtZ6x for ; Fri, 30 Jun 2017 17:42:50 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 4960512EB17 for ; Fri, 30 Jun 2017 17:42:50 -0700 (PDT) X-AuditID: 1209190d-d83ff7000000498b-49-5956f0086654 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id BF.C6.18827.800F6595; Fri, 30 Jun 2017 20:42:49 -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 v610gl1p021833 for ; Fri, 30 Jun 2017 20:42:48 -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 v610gk11012915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Jun 2017 20:42:47 -0400 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <76A645C6-DA62-45A8-8D4D-B44322583DA7@mit.edu> Date: Fri, 30 Jun 2017 20:42:45 -0400 To: "" X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixG6nosv5ISzS4N9XRouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEro/VRK3PBbYWKG9fnMDUw7pPqYuTkkBAwkXgz/QVzFyMXh5DA YiaJC7M/sUM4xxglpmw+yALhfGOSWN3XwgbSwiagKjF9TQsTiM0soC7xZ94lZghbW2LZwtdA NgcHr4C+RO9zRpCwMJC599kSdhCbV8BK4suubWBjWIDGHHu/ixXEFgEas+b8TyaIi2Qlbs2+ xDyBkXcWkg2zkGyYhbBhASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjKBQ 4pTk3cH4767XIUYBDkYlHt4NIWGRQqyJZcWVuYcYJTmYlER5V14LjRTiS8pPqcxILM6ILyrN SS0+xCjBwawkwvvsLVA5b0piZVVqUT5MSpqDRUmcV1yjMUJIID2xJDU7NbUgtQgmK8PBoSTB ++8dUKNgUWp6akVaZk4JQpqJgxNkOA/Q8ClnQIYXFyTmFmemQ+RPMepyvJrw/xuTEEtefl6q FNAakEECIEUZpXlwc0ApIOHtYdNXjOJAbwnz7gSp4gGmD7hJr4CWMAEtEZ4RArKkJBEhJdXA qDr1menh4FsMPgUZf3vfOUssPHDko86U3qumyiFCBgfyvvP7Gll5ZLRWlvVdudn6tKrsZ5xz /JSttStsa05ynog24G1p+ShZ8/HTv9r4E49yT+j905R4+Svlk+zXc7NUpl2/8bk1/WVt1prA NXOa3kb1NN3U/lFl/m/LIoF3LkL168Pund0spMRSnJFoqMVcVJwIAGo9k3PcAgAA Archived-At: Subject: [OAUTH-WG] Different use case for the Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 00:42:52 -0000 Since the draft is close to final, I wanted to write to the list about a = use case in a project that I=E2=80=99m working on that I think is = valuable input into the Device Flow discussion. This use case exercises the device flow OAuth extension grant in an = interesting way. The usual line of thinking for using this flow is that = there=E2=80=99s a disadvantaged device, like a set-top box, that the = user needs to grant access to using a separate personal computer. In = this use case, there are still two devices but it=E2=80=99s the = permissions that vary between them, not the platform capabilities. The = device ultimately getting the access token is the user=E2=80=99s = personal mobile device (a phone or tablet), but they=E2=80=99re unable = to log in and authorize the device directly on the device itself. = Instead, the user needs to bring their device to an authorized kiosk = staffed by a trained entity who has the authority to onboard the device = to the user=E2=80=99s account. Good news is that so far we=E2=80=99ve = been able to build this out using the device flow with no modifications = to the protocol, but since our use is different we thought it would be = good for the community to see its details. =20 The flow starts with the user on their device, we=E2=80=99ll use a = smartphone in our example. The user provides an identifier to their = account, and the device starts the device flow to the server including = this identifier as an additional parameter. The AS generates a device = and user code pair and ties that to the account indicated by the = identifier. Later, the user brings their device in to the staffed kiosk, = where the authorized staff verifies the user (using a physical ID card) = and the device (using the user code) against the =E2=80=9Cpending=E2=80=9D= requests for that user=E2=80=99s account. The staff person makes sure = that the user who=E2=80=99s present is the same as the user in the = pending request and approves the connection. At the AS this sets a flag = on the device code and binds it strongly to that user=E2=80=99s account. = Note that it=E2=80=99s the staff person who=E2=80=99s logged in, but the = binding is to the proofed user=E2=80=99s account. This decision is = written to an audit log (a good potential application for the SecEvents = group, since it=E2=80=99s an event with multiple parties that needs to = be verifiable). Later, the user gets their device online again and it = trades the device code for the access token, and now it can call the = APIs as needed.=20 =20 The time gaps in this use case are much larger than is typical with the = device flow. When setting up a set-top box, it would be expected that = everything gets set up within a few minutes. However, the requirement = for the user to potentially travel to a trusted kiosk means that our = device codes last for up to a week. And once the device is approved by = the authorized staff person at the kiosk, the user has *another* week to = get their device back online to trade the device code in for an access = token. If either of those windows are missed, they have to start the = whole process over again.=20 =20 Apart from the account identifier in the initial request for the device = code (which we read as being allowed), there are no changes to the = device code flow protocol. The account identifier is more for increasing = the usability of the entire system, as it allows a user=E2=80=99s = pending devices to be verified more quickly at the kiosk. Also, in this = particular deployment, it=E2=80=99s used along with dynamic registration = and private_key_jwt authentication for the clients, which allows for = greater security for the overall protocol and greater separation of = client instances from each other.=20 =20 We=E2=80=99re interested to hear people=E2=80=99s feedback on our use of = the device flow, and curious if anyone else is using it in a similar = fashion. Even though it=E2=80=99s different, it still fits the spirit of = =E2=80=9Ctwo devices with different capabilities=E2=80=9D present in the = draft.=20 =20 =E2=80=94 Justin=
3D"Ping
Brian Campbell
Distinguished Engineer =
bcampbell@pingidentity.com
w: +1 720.317.2061
c: +1 = 303.918.9415
=
Connect with us: 3D"Glassdoor 3D"LinkedIn = 3D"twitter= 3D"facebook 3D"youtube 3D"Google+= 3D"Blog