From nobody Mon Oct 1 15:23:49 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB0912008A for ; Mon, 1 Oct 2018 15:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gMUKtT2_lyVd for ; Mon, 1 Oct 2018 15:23:47 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6399130E6F for ; Mon, 1 Oct 2018 15:23:46 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id n18-v6so10793363ioa.9 for ; Mon, 01 Oct 2018 15:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pKVt/croT8RGsgemLkxG91YYv7921pZnVaJmyqxLCgc=; b=DLiFuW76L54JbWB9wOv/V5nYr7K01yrwOAmF68iqnFE6IaLKrE0WuYtv79ySmeiWPF a5jAa/93BTiGv44r2rU1ZEAOtgDlVjRQhP/qiCKHraRkpjbm4qsScZ7upzwwh7m+Yc70 TVt+XTb1ctkMkSW+HXzy8Pfy7OCrf4QYubQlc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pKVt/croT8RGsgemLkxG91YYv7921pZnVaJmyqxLCgc=; b=EUoKcJCpYfeFsRfDPqfTsG/wMveU0rLetynlzCSYfY0w773k9qkfMe1UZfzu4VDCk9 3T3VT8+QKZY1wnvfaN7UWQX+1n42PhH2ttrdyo/ENc3qGdYGt2Qt6TvyRNMFF/du6plg W3kBpA8xNLy4mtl3TInub/VCpAS0o5SZ95CuLabl2QPFRkwwBCZgen7kFuOiK33LjsbQ 1dKoPH2Jc7hMsguD/aieMi7CKC0Xir9Vaat5gB0eX1VT23ivDHUXrs2+Iwb/o2DOQJjL 19FnTD7i/+MyxM1BiQlmnqr8fSnSpldNJGUGHiVLUxU3RavMXbufk3O++ZvMZO0mO3A1 NlLw== X-Gm-Message-State: ABuFfoiF6PaNQWxI1fExRUHN7oHQ4d8zgAKt31uIl2oNUFvBgtiZeNeR V+2SS3x3LBxWJly9hCqtRnhMerrqPgzS7mJFvd6UR3a3zuFKfbyJoZj5beQ1EESt/8xKp94BqK5 15zXA06mh58BrxBvoAgM= X-Google-Smtp-Source: ACcGV62GXt1XI+wcxGenrpbdnH+Qb8zyUMGeSxmtC+kvqh+fBns5Aapk4CHXnAElsBE31gUD1Ix5HyZdfqzBGJifhDQ= X-Received: by 2002:a6b:7104:: with SMTP id q4-v6mr6493500iog.138.1538432624519; Mon, 01 Oct 2018 15:23:44 -0700 (PDT) MIME-Version: 1.0 References: <153316758904.21922.15270209647384469158@ietfa.amsl.com> In-Reply-To: <153316758904.21922.15270209647384469158@ietfa.amsl.com> From: Brian Campbell Date: Mon, 1 Oct 2018 16:23:18 -0600 Message-ID: To: oauth , draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="0000000000001885690577324222" Archived-At: Subject: [OAUTH-WG] missing IANA registration for ? Fwd: I-D Action: draft-ietf-oauth-device-flow-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 22:23:49 -0000 --0000000000001885690577324222 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I realize this is very late in this draft's life cycle but I just noticed it while working on something different but coincidentally similar. The device flow defines a device_code parameter to be used in the access token request to the token endpoint[1] but doesn't register it as a token request parameter in the IANA Considerations[2] as would be expected/suggested by RFC6749's OAuth Parameters Registry[3]. Should the device flow register the device_code parameter? Seems like it probably should. [1] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12#section-3.4 [2] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12#section-7 [3] https://tools.ietf.org/html/rfc6749#section-11.2 ---------- Forwarded message --------- From: Date: Wed, Aug 1, 2018 at 5:53 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-12.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-12.txt Pages : 20 Date : 2018-08-01 Abstract: This OAuth 2.0 authorization flow for browserless and input- constrained devices, often referred to as the device flow, enables OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method (such as a smart TV, media console, picture frame, or printer), or lack a suitable browser for a more traditional OAuth flow. This authorization flow instructs the user to perform the authorization request on a secondary device, such as a smartphone. There is no requirement for communication between the constrained device and the user's secondary device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-device-flow-12 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000001885690577324222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I realize this is very late in th= is draft's life cycle but I just noticed it while working on something = different but coincidentally similar.

The dev= ice flow defines a device_code parameter to be used in the access token req= uest to the token endpoint[1] but doesn't register it as a token reques= t parameter in the IANA Considerations[2] as would be expected/suggested by= RFC6749's OAuth Parameters Registry[3].

Shou= ld the device flow register the device_code parameter? Seems like it probab= ly should.

[2] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12#section-7<= /a>
=

------= ---- Forwarded message ---------
From: <internet-drafts@ietf.org>Date: Wed, Aug 1, 2018 at 5:53 PM
Subject: [OAUTH-WG] I-D Action: draft= -ietf-oauth-device-flow-12.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 WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Will= iam Denniss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-device-flow-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-08-01

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft= -ietf-oauth-device-flow/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oa= uth-device-flow-12
https://datatracker.ietf.org/do= c/html/draft-ietf-oauth-device-flow-12

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


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. --0000000000001885690577324222-- From nobody Mon Oct 1 15:57:20 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24428129619 for ; Mon, 1 Oct 2018 15:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82mjGAfhEEmT for ; Mon, 1 Oct 2018 15:57:15 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54949124C04 for ; Mon, 1 Oct 2018 15:57:15 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id w200-v6so693091itc.4 for ; Mon, 01 Oct 2018 15:57:15 -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=n0bIrDQk2u1iAszUgDX7bvMKFW9PDD/iwpEtH4S4DGA=; b=tZXDYiALP5C0L1MZwl4yvG8NZdlu7wQ+fb2KWRxO9joiLRfMvDkyxiDDytoDXbcTDn 3UgWHEGIY4DaTFUCILjNVzehvLPWr6hOSBEN9kYcReFQ7N7WNDctGoB1Km+uRzko8vHq Ndbx9ZCxseFcugNRBIMvhXPXxSj6rDWpBseOHfqjL0/epd90ShCIrB82yzLIm1vE8oM/ lgHoTnehX7apfkQwvRsgO8IwZMha05qoovA8U0Lqq4hobbE4hZBj2XvFYmh3bIHoAjxr av2Tfqe0KBWF2DSTmb3lbcyt0FxwkW7RHEGf5WUI5XRYtkfSVY1nEsxRYuQi5Qn7Z8UO hUEg== 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=n0bIrDQk2u1iAszUgDX7bvMKFW9PDD/iwpEtH4S4DGA=; b=NYxfQVRyt/nEncruRnjjus6IHJED08bniNgpUwjOUkFwIVqhAsPOUo9H8iqKD1nkcN Sfkj5sdOVlPF0mLXaMrwiCKg1dwxhdO3u5yICvwAR05KPJ0QFa/vt/EOJTwoECrhsPSD WfwjNbZIBX7J7sQOlx4/Chrt+ZdBV9VAPYT34kc1BjfFYxFb6LH7hVVxQBdwRCGWv1Y3 JLXjuTtkvxpO91yf94pKmkrKEscwPGsikdquWvCRO1EMOhi3r7e6ixc9VQ4qHLgjm2Fv OdxWw8bp7hfgsmTumK0Pq2aOBtJrXdjvzGMpJPAWTknHgmp70wNQhcRzKUqU8ZsxjLwv dBCw== X-Gm-Message-State: ABuFfog6XRSwAPJlV7sgigCpnXbybYgT9+HFJ1bQx4FZ2lWm+rMQx+v6 sGIr+eGlVPnNPQIpYtcUpEa2dDLt5iFo4eGHsEOFqMWwCu4Lbw== X-Google-Smtp-Source: ACcGV60MdP3Ept2cr7N0QnzQjyyONrDQy1reKsi7g3NYkuNs+W39a7dpcd1bzxyxq60MPSJLrcx2knohsdOvEuskPSs= X-Received: by 2002:a02:9d28:: with SMTP id n37-v6mr10553010jak.80.1538434634219; Mon, 01 Oct 2018 15:57:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:e30a:0:0:0:0:0 with HTTP; Mon, 1 Oct 2018 15:56:53 -0700 (PDT) In-Reply-To: References: <153316758904.21922.15270209647384469158@ietfa.amsl.com> From: William Denniss Date: Mon, 1 Oct 2018 15:56:53 -0700 Message-ID: To: Brian Campbell Cc: oauth , draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="000000000000e27035057732b9a6" Archived-At: Subject: Re: [OAUTH-WG] missing IANA registration for ? Fwd: I-D Action: draft-ietf-oauth-device-flow-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 22:57:19 -0000 --000000000000e27035057732b9a6 Content-Type: text/plain; charset="UTF-8" Hi Brian, Thank you for catching this, I believe you are correct. Specifically, the "device_code" param when used on the token endpoint https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12#section-3.4 should be registered. I will make this change. Note that "device_code" (and other params) are also returned in the "Device Authorization Response" however there is no "Parameter usage location" category in the "OAuth Parameters Registry" for that endpoint. William On Mon, Oct 1, 2018 at 3:23 PM, Brian Campbell wrote: > I realize this is very late in this draft's life cycle but I just noticed > it while working on something different but coincidentally similar. > > The device flow defines a device_code parameter to be used in the access > token request to the token endpoint[1] but doesn't register it as a token > request parameter in the IANA Considerations[2] as would be > expected/suggested by RFC6749's OAuth Parameters Registry[3]. > > Should the device flow register the device_code parameter? Seems like it > probably should. > > [1] https://tools.ietf.org/html/draft-ietf-oauth-device-flow- > 12#section-3.4 > [2] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12#section-7 > [3] https://tools.ietf.org/html/rfc6749#section-11.2 > > > ---------- Forwarded message --------- > From: > Date: Wed, Aug 1, 2018 at 5:53 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-12.txt > To: > Cc: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Device Flow for Browserless and Input > Constrained Devices > Authors : William Denniss > John Bradley > Michael B. Jones > Hannes Tschofenig > Filename : draft-ietf-oauth-device-flow-12.txt > Pages : 20 > Date : 2018-08-01 > > Abstract: > This OAuth 2.0 authorization flow for browserless and input- > constrained devices, often referred to as the device flow, enables > OAuth clients to request user authorization from devices that have an > Internet connection, but don't have an easy input method (such as a > smart TV, media console, picture frame, or printer), or lack a > suitable browser for a more traditional OAuth flow. This > authorization flow instructs the user to perform the authorization > request on a secondary device, such as a smartphone. There is no > requirement for communication between the constrained device and the > user's secondary device. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-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/ > > _______________________________________________ > 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.* --000000000000e27035057732b9a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi= Brian,

Thank you for catching this, I believe you= are correct.

Specifically, the "device_code&= quot; param when used on the token endpoint https://tools.ietf.org= /html/draft-ietf-oauth-device-flow-12#section-3.4 should be registered.= =C2=A0 I will make this change.

Note that "de= vice_code" (and other params) are also returned in the "Device Au= thorization Response" however there is no "Parameter usage locati= on" category in the "OAuth Parameters Registry"=C2=A0for tha= t endpoint.

William
<= div class=3D"gmail_extra">
On Mon, Oct 1, 201= 8 at 3:23 PM, Brian Campbell <bcampbell@pingidentity.com><= /span> wrote:
I realize this is very late in this draft's life cycle= but I just noticed it while working on something different but coincidenta= lly similar.

The device flow defines a device= _code parameter to be used in the access token request to the token endpoin= t[1] but doesn't register it as a token request parameter in the IANA C= onsiderations[2] as would be expected/suggested by RFC6749's OAuth Para= meters Registry[3].

Should the device flow regist= er the device_code parameter? Seems like it probably should.



---------- Forwarded messag= e ---------
From: <internet-drafts@ietf.org>
Da= te: Wed, Aug 1, 2018 at 5:53 PM
Subject: [OAUTH-WG] I-D Action: draft-ie= tf-oauth-device-flow-12.txt
To: <i-d-announce@ietf.org>
Cc: <oauth@ietf.org>
<= /div>


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Will= iam Denniss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-device-flow-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-08-01

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-oauth-device-flow-12
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-12

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


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.

<= /div> --000000000000e27035057732b9a6-- From nobody Tue Oct 9 09:49:46 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B358C13135D for ; Tue, 9 Oct 2018 09:49:44 -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 1oNrjFtyxImN for ; Tue, 9 Oct 2018 09:49:43 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F509131332 for ; Tue, 9 Oct 2018 09:49:43 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id z16-v6so1696337iol.6 for ; Tue, 09 Oct 2018 09:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hyggYnI45ENQYi6E4JNdZAAIAHssg2SyDFELNj6zRU4=; b=jFOOS3GQIA9KcyoSzr+IawtGf8uepgPyhfWYBhJrCO7xodnjWx12WR5z8/2dU7RcUa Qac+eTDMZjaQcXjgFMWCr02RI/VkFyA7A4MhUM6sNYnowYauhs2636U+aTLfkTTzNKGe C1rNpG5VgzuyovcYXHYq0AXbXyQsFBtJH09K97YYzg9+8tByUcrQyxROXUGnsh1G9BCg Vh6z8H1nypOyibYJqso5Hahy6zH3aZAa7fcLx8twBdCwmLNelYAp3+pNL9fLFcxYWdGe XN8aYFCJS/e9ZNugI/NE6MDb/9sLKy3Qjer/o8H5cu6SLNNjzyU0Ub0cy0JpERIXXGHS u8kw== 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=hyggYnI45ENQYi6E4JNdZAAIAHssg2SyDFELNj6zRU4=; b=qFER+XnkRGQZwmKRNKlv8q4hkHuQkUmQk1XjMXhz19fh+TErWto6mQBd8XljbgUDo3 r55tiwoH2NDn086Jlp7a1BaC2hVN1vMLb5iKE93x/47ig0QkQUmHGUnxfw7a8Mjj6J5u lldIH4Nf6ZLVTDc0aiY1G6XdYKao0ubhYaU4JFPKDsFmzRePTNoorqKnPsK8IcZtVds4 WPFZkPYEcI4WvWQ5qjiRS++C9iPFYtWr08mZ50G7HINux8YAVIdqHBZ3nxO+92Zebfem tt76eOUkNs9vVzLraTS3/wDCqPdHBDLOTKjDX7WZP0YkTyMqR4XNEtjpTI6yu3EJuhqS TRYQ== X-Gm-Message-State: ABuFfojN4AfDFm5qqOs8Fs4w/X7H7oLSyrUSDeTU+3ADQlb3DsBoqM8L Dizd7rwv881Vk0JfcL4uEyVLbV4Wo7hoPEvGAGRUItlgGuI= X-Google-Smtp-Source: ACcGV63Jju+UMO1KC+zokS1F7WOkcCMQv2v1O3wFbhd2bDVaY2w5iGUboRbqyGZihIfLzsQB4HD+z5ig916UjEWsOGk= X-Received: by 2002:a6b:c785:: with SMTP id x127-v6mr17304054iof.99.1539103782250; Tue, 09 Oct 2018 09:49:42 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Tue, 9 Oct 2018 12:50:46 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000036aef30577ce86e2" Archived-At: Subject: [OAUTH-WG] OAuth WG draft agenda for Bangkok X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:49:45 -0000 --00000000000036aef30577ce86e2 Content-Type: text/plain; charset="UTF-8" All, Here is our draft agenda for the Bangkok meeting: * Chairs Update * Torsten Lodderstedt - draft-ietf-oauth-security-topics - draft-ietf-oauth-jwt-introspection-response - openid-financial-api-jarm-wd * Omer Levi Hevroni (remote) - draft-hevroni-oauth-seamless-flow * Brian Campbell - draft-ietf-oauth-resource-indicators - draft-ietf-oauth-token-binding * Brian Campbell - quick update on the following: - draft-ietf-oauth-mtls - draft-ietf-oauth-token-exchange We might have one more topic that might be added to the list later this week. Any other topics? Regards, Rifaat & Hannes --00000000000036aef30577ce86e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,<= /font>

Here is our draft agenda for the Bangkok meet= ing:

=
* Chairs Update
<= div>
* Torsten Lodderstedt
- draft-ietf-oauth-security-topics
<= div>- draft-ietf-oauth-jwt-introspectio= n-response
- openid-fi= nancial-api-jarm-wd
* Omer Levi Hevroni= (remote)
- draft-hevr= oni-oauth-seamless-flow
* Brian Campbel= l
- draft-ietf-oauth-r= esource-indicators
- d= raft-ietf-oauth-token-binding

* Brian C= ampbell - quick update on the following:
- draft-ietf-oauth-mtls
- draft-ietf-oauth-token-exchange

We might have one more topic that might be added to the l= ist later this week.

Any other topics?
<= br>
Regards,
=C2=A0Rifaat & Hannes
--00000000000036aef30577ce86e2-- From nobody Tue Oct 9 17:19:04 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FD1130E39 for ; Tue, 9 Oct 2018 17:19: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, 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 gZy2QBJILUZS for ; Tue, 9 Oct 2018 17:18:59 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B866D130E17 for ; Tue, 9 Oct 2018 17:18:59 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id p4-v6so2613132iom.3 for ; Tue, 09 Oct 2018 17:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=t1zxDAe4ZjW5m9PntgJpWORN4t/kSCufCzeb36B7kdg=; b=DmSq0u5brtWtfXZXso1P8Qw1lp05AC96wrQZAyP9uiy5VEJQsdrt6VeA72sv0Mu4F1 uwCKQCO50NLH710c6DyJZgdPA6DjzfHWYgp+Lwo/E/PlWbg9JPoA98DgjaWiyNWA+hbz N97NXQpT/bGIoEJRBqnYtAw/yOvuwN0Qe9f6k= 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=t1zxDAe4ZjW5m9PntgJpWORN4t/kSCufCzeb36B7kdg=; b=DubvyKyNVupgMSJm+EdW7lRU4XUnO3cm4We7Lecm7cm5miYQ/EtmIaI9bFDXaD4iR3 FAvHXIIqKIcJmgenV35E+qpdfBdTiFIH42I1Hp8EdOU9cbcJbnXiP7vxas8jKfJUE0bP /6Im20q5KrdWMMtvmiRNN+HaWTBWT4pA/wUvvgskGHzpg4d0triIzLXO1QRCcxI6g4f8 23lLxGmLnwKjxV//t7poN7ZF9q44ch8WLCk+QibZrmVSZPPWkB59KyDZ/OHEAOcHdLTU j0r4SpZHVBN89oTOr74c6YT2zCjsUno5EIvHOa53Os+3Oqawi3AK4ReR0lrLaNKeAcby Oo7g== X-Gm-Message-State: ABuFfoiiL8akJ/Xs25rTcA0I4CtdTxzoB6SUhXb3nNuGU3C7fpiOq7UQ X5yQWIaCHoBC6vtHgEoEM3XRYZYrUOFKFddKh2/Mx+/Yfspz7M+rpF6fkdpjJKNSa/dqZOckC8E NxJJApMEaLcr3nWx/ogE= X-Google-Smtp-Source: ACcGV62mW2X8HKWc/hoMXUn5sj3CxzcbMmMgpT9+IL1mtvVqGfMw+/N5P0KGRfM4ATuCXDtbtgDwBw7b/MMaSjWg180= X-Received: by 2002:a5e:d809:: with SMTP id l9-v6mr21374599iok.238.1539130738431; Tue, 09 Oct 2018 17:18:58 -0700 (PDT) MIME-Version: 1.0 From: Brian Campbell Date: Tue, 9 Oct 2018 18:18:32 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000ed837a0577d4cc5c" Archived-At: Subject: [OAUTH-WG] late off-list developer feedback on OAuth MTLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 00:19:03 -0000 --000000000000ed837a0577d4cc5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A couple of the draft-ietf-oauth-mtls editors recived some off-list questions and feedback from an implementer, which resulted in a few small potential clarifying updates to the document that I think are worth incorporating despite the post WGLC status. Barring reasonable objections from the WG or process objections from the chairs, I'd like to make these updates. Basically, there were two points of confusion. First, there was some uncertainty about the order of operations and encoding steps when computing the "x5t#S256" value. In order to be more specific/clear, I propose changing the relevant text in sec 3.1 from: To represent the hash of a certificate in a JWT, this specification defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value of the "x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint, fingerprint or digest) of the DER encoding of the X.509 certificate [RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=3D' characters omitted and without the inclusion of any line breaks, whitespace, or other additional characters. to: To represent the hash of a certificate in a JWT, this specification defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value of the "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash (a.k.a. thumbprint, fingerprint or digest) of the DER encoding of the X.509 certificate [RFC5280]. The base64url-encoded value MUST omit all trailing pad '=3D' characters MUST NOT include any line breaks, whitespace, or other additional characters. And also, as a way for developers to check their work. to add an example with a certificate and the "x5t#S256" value for it. Second was some confusion about matching the cert/key against the keys in the client's JWK Set for the self-signed mode. It was said that having some text to the effect of '(e.g. "n" and "e" for RSA, "x" and "y" for EC)' along with the text note at the end of Section 2.2.2 . would have been helpful. So that paragraph would change from: For the Self-Signed Certificate method of binding a certificate to a client using mutual TLS client authentication, the existing "jwks_uri" or "jwks" metadata parameters from [RFC7591 ] are used to convey the client's certificates and public keys, where the X.509 certificates are represented using the JSON Web Key (JWK) [RFC7517 ] "x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key in the first certificate of the "x5c" parameter must match the public key represented by other members of the JWK). to: For the Self-Signed Certificate method of binding a certificate to a client using mutual TLS client authentication, the existing "jwks_uri" or "jwks" metadata parameters from [RFC7591 ] are used to convey the client's certificates and public keys, where the X.509 certificates are represented using the JSON Web Key (JWK) [RFC7517 ] "x5c" parameter. Note that Sec 4.7 of RFC 7517 requires that the key in the first certificate of the "x5c" parameter must match the public key represented by other members of the JWK (e.g. "n" and "e" for RSA, "x" and "y" for EC). --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ed837a0577d4cc5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A couple of the draft-ie= tf-oauth-mtls editors recived some off-list questions and feedback from an = implementer, which resulted in a few small potential clarifying updates to = the document that I think are worth incorporating despite the post WGLC sta= tus.

= Barring reasonable objections from the WG or process objections from the ch= airs, I'd like to make these updates.=C2=A0
=
Basically, there were two points of confusion.

First, there was some uncertainty a= bout the order of operations and encoding steps when computing the "x5= t#S256" value.=C2=A0 In order to be more specific/clear, I propose cha= nging the relevant text in sec 3.1 from:=C2=A0 

To represent the hash of a cer=
tificate in a JWT, this specification
defines the new JWT Confirmation Me=
thod [RFC7800] member "x5t#S256"
for the X.509 Certificate SHA-=
256 Thumbprint.  The value of the
"x5t#S256" member is the SHA-=
256[SHS] hash (a.k.a. thumbprint,
fingerprint or digest) of the DER encod=
ing of the X.509 certificate
[RFC5280] base64url-encoded [RFC4648] with w=
ith all trailing pad '=3D'
characters omitted and without the inc=
lusion of any line breaks,
whitespace, or other additional characters.

<= div>
to:

To repre= sent the hash of a certificate in a JWT, this specification
defines the new= JWT Confirmation Method [RFC7800] member "x5t#S256"
=
for the X.50= 9 Certificate SHA-256 Thumbprint.=C2=A0 The value of the
=
"x5t#S256&quo= t; member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash (a.k.a.
thumb= print, fingerprint or digest) of the DER encoding of the X.509 certificate<= /font>
[RFC5280]. The base64url-encoded value MUST omit all trai= ling pad '=3D' characters
MUST NOT include any line breaks, wh= itespace, or other additional characters.

And also, as a= way for developers to check their work. to add an example with a certifica= te and the "x5t#S256" value for it.

Second was some confusion about matching the cert/key against the keys in = the client's JWK Set for the self-signed mode. It was said that having = some text to the effect of '(e.g. "n" and "e" for R= SA, "x" and "y" for EC)' along with the text note a= t the end of Section 2.2.2. would have been helpful. So that paragr= aph would change from:

   For the Self-Signed Certificate method of binding a certificate to a
   client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to
   convey the client's certificates and public keys, where the X.509
   certificates are represented using the JSON Web Key (JWK) [RFC7517]
   "x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key
   in the first certificate of the "x5c" parameter must match the=
 public
   key represented by other members of the JWK).

to:

   For the Self-Signed Certificate=
 method of binding a certificate to a
   client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to
   convey the client's certificates and public keys, where the X.509
   certificates are represented using the JSON Web Key (JWK) [RFC7517]
   "x5c" parameter. Note that Sec 4.7 of RFC 7517 requires that the key
   in the first certificate of the "x5c" parameter must match the=
 public
   key represented by other members of the JWK (e.g. "n" and &quo=
t;e" for RSA,
=C2=A0  "x" and "y" for EC).




=C2=A0 =C2=A0 =C2=A0 <= /div>



<= /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. --000000000000ed837a0577d4cc5c-- From nobody Fri Oct 12 10:24:42 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97343130E52 for ; Fri, 12 Oct 2018 10:24: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 Dm3mV9w4_Wlt for ; Fri, 12 Oct 2018 10:24:39 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44BC130E4D for ; Fri, 12 Oct 2018 10:24:39 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id m16-v6so9782862ioj.4 for ; Fri, 12 Oct 2018 10:24:39 -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=SfU/Zj/P5sTUUCjP4mfBJWj+8b3OzYrNhK/SQu6RzpU=; b=ollX5ajOos+fp8NpFgVrKSdwqPWRRrPMxp5F1fWo0WW/htagbqCfzEmmt5VtOnntXd XqweBJd8EKhbv5MZAU1rGa5hJKbwgbKrlmkm8S5K3pnUkTOLCo6FkUQNvJXMhS39C51N SHL0Q1CTx3pUyeMKlzUC6EokeXQpdtMrEmUHCMjCfH2E5xzdaSRNZAYOTkEVddHT09D9 0rgFgnW/kRZn8FqHodo5Gq7t/dJjWGz2sWO8MSrwTKMco9HeL11CTU8RQrWXooNfuZNY 2ZCvC1JjgR1tBTsmLx/vIaAbQcwKZDAeVobiK3vhPuOqquiZxVRW3h8TB9VDRJaE81Ig GA5w== 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=SfU/Zj/P5sTUUCjP4mfBJWj+8b3OzYrNhK/SQu6RzpU=; b=kMCLdR9v6FlzW2wDMtm+gLBCSGLbKTvAKdTff8iQZwjfxTZC+6uoXS5G1N8WE6d2sR td0yfgIAR62bgO7GJ791tMrzp/YQnT98ID3m/ld8JkTejUGRo84muV8oJA2tvsiChFVc 4A+TghENGOuUo8xtQrNMihH0UlhZ8Mh/HmfuAfRp5HXKURseIZ1KYp7PJ2jhsg2+sfN9 WR5Ab9DkSIiV5SNMLx6UmZLeMXejkhe2RowBOC5Mpnv9JqwJXVhdG3eYKsGJPm3qTAdO nnrlcomyWnAWCRgsDp+T+9SDV0uHNwasnP5MjLBv0gGRILuzLH3+zorxIUtO8/G6XsRx 6MLg== X-Gm-Message-State: ABuFfogPVJ+qGDc8KDkcAFfDGl+BC0zVEpq4T3lQ8JXbE31VJSzgbf7W Ycn1gtxWUlqH2GLnfJCkCamnGU2/rLa+2FEaox9g/cfiwdM= X-Google-Smtp-Source: ACcGV627PkDoqe1UHc3hGvYpGRto2a1ZSV4iLSi3PzOa+xXJDGw155Ec/7j1zjHfKE0Zozs4UaHBOJWUeiFww59uV1g= X-Received: by 2002:a6b:c785:: with SMTP id x127-v6mr4186988iof.99.1539365078855; Fri, 12 Oct 2018 10:24:38 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Fri, 12 Oct 2018 13:25:44 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000b4737005780b5c5d" Archived-At: Subject: [OAUTH-WG] IETF103 OAuth Final Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 17:24:41 -0000 --000000000000b4737005780b5c5d Content-Type: text/plain; charset="UTF-8" All, Here is our final agenda for Bangkok: https://datatracker.ietf.org/meeting/103/materials/agenda-103-oauth-02 9:00-11:00 Tuesday Morning session I Chairs Update 10min Torsten Lodderstedt - draft-ietf-oauth-security-topics 30min - draft-ietf-oauth-jwt-introspection-response 30min - openid-financial-api-jarm-wd 15min Hannes Tschofenig - draft-ietf-oauth-pop-key-distribution 20min Omer Levi Hevroni (remote) - draft-hevroni-oauth-seamless-flow 15min 11:20-12:20 Tuesday Morning session II Brian Campbell - draft-ietf-oauth-resource-indicators 20min - draft-ietf-oauth-token-binding 20min - draft-ietf-oauth-mtls 10min - draft-ietf-oauth-token-exchange 10min Regards, Rifaat & Hannes --000000000000b4737005780b5c5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,<= /font>

Here is our final agenda for Bangkok:<= /div>
= 
9:00-11:00	Tuesday=
 Morning session I

Chairs Update                                       10min

Torsten Lodderstedt
- draft-ietf-oauth-security-topics                  30min
- draft-ietf-oauth-jwt-introspection-response       30min
- openid-financial-api-jarm-wd                      15min

Hannes Tschofenig
 - draft-ietf-oauth-pop-key-distribution            20min

Omer Levi Hevroni (remote)
- draft-hevroni-oauth-seamless-flow                 15min


11:20-12:20	Tuesday Morning session II

Brian Campbell
- draft-ietf-oauth-resource-indicators              20min
- draft-ietf-oauth-token-binding                    20min
- draft-ietf-oauth-mtls                             10min
- draft-ietf-oauth-token-exchange                   10min

<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">Re= gards,
 Rifaat & Hannes

--000000000000b4737005780b5c5d-- From nobody Sat Oct 13 01:52:03 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1D7130DE8 for ; Sat, 13 Oct 2018 01:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 an6X5VAQdF9Q for ; Sat, 13 Oct 2018 01:51:59 -0700 (PDT) Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (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 62743130EC9 for ; Sat, 13 Oct 2018 01:51:58 -0700 (PDT) Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id BFeNgB2vmSLBXBFeOgY4Yv; Sat, 13 Oct 2018 01:51:57 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== Organization: Connect2id Ltd. Message-ID: <4d27c396-24f4-4649-0585-826ff9ce1dbf@connect2id.com> Date: Sat, 13 Oct 2018 11:51:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020702030600060506050501" X-CMAE-Envelope: MS4wfMaXuHqaVm/W4eL7a1bjpw6yD2ZFWmPSDUV+hC03Idse2ZSEpA8ZNJPPAtY5cnHugu5A6H1YFrokX0Cg7NO8VAPAaxDkIbkpODcJzMk8YcgsvLACJXfN uKdr+WJ6BEAB8YkxJzmTyy6Wprv7+iZpqYPyILO69gQRwK9e9LVlWvyo Archived-At: Subject: Re: [OAUTH-WG] late off-list developer feedback on OAuth MTLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 08:52:02 -0000 This is a cryptographically signed message in MIME format. --------------ms020702030600060506050501 Content-Type: multipart/alternative; boundary="------------4DBCCE586D39450CE1511984" Content-Language: en-US This is a multi-part message in MIME format. --------------4DBCCE586D39450CE1511984 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Brian, this makes the spec even better! I have just this one small note, there seems to be an "and" missing here:= The base64url-encoded value MUST omit all trailing pad '=3D' characters _= and_ MUST NOT include any line breaks, whitespace, or other additional ch= aracters. Vladimir On 10/10/18 03:18, Brian Campbell wrote: > A couple of the draft-ietf-oauth-mtls editors recived some off-list > questions and feedback from an implementer, which resulted in a few sma= ll > potential clarifying updates to the document that I think are worth > incorporating despite the post WGLC status. > > Barring reasonable objections from the WG or process objections from th= e > chairs, I'd like to make these updates. > > Basically, there were two points of confusion. > > First, there was some uncertainty about the order of operations and > encoding steps when computing the "x5t#S256" value. In order to be mor= e > specific/clear, I propose changing the relevant text in sec 3.1 > from= : > > To represent the hash of a certificate in a JWT, this specification > > defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" > > for the X.509 Certificate SHA-256 Thumbprint. The value of the > > "x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint, > > fingerprint or digest) of the DER encoding of the X.509 certificate > > [RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=3D' > > characters omitted and without the inclusion of any line breaks, > > whitespace, or other additional characters. > > > to: > > To represent the hash of a certificate in a JWT, this specification > defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" > for the X.509 Certificate SHA-256 Thumbprint. The value of the > "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash > (a.k.a. > thumbprint, fingerprint or digest) of the DER encoding of the X.509 > certificate > [RFC5280]. The base64url-encoded value MUST omit all trailing pad '=3D'= > characters > MUST NOT include any line breaks, whitespace, or other additional > characters. > > > And also, as a way for developers to check their work. to add an exampl= e > with a certificate and the "x5t#S256" value for it. > > Second was some confusion about matching the cert/key against the keys = in > the client's JWK Set for the self-signed mode. It was said that having = some > text to the effect of '(e.g. "n" and "e" for RSA, "x" and "y" for EC)' > along with the text note at the end of Section 2.2.2 > . w= ould > have been helpful. So that paragraph would change from: > > For the Self-Signed Certificate method of binding a certificate to a= > client using mutual TLS client authentication, the existing > "jwks_uri" or "jwks" metadata parameters from [RFC7591 > ] are used to > convey the client's certificates and public keys, where the X.509 > certificates are represented using the JSON Web Key (JWK) [RFC7517 > ] > "x5c" parameter (note that Sec 4.7 of RFC 7517 > requires that the key > in the first certificate of the "x5c" parameter must match the publi= c > key represented by other members of the JWK). > > to: > > For the Self-Signed Certificate method of binding a certificate to a= > client using mutual TLS client authentication, the existing > "jwks_uri" or "jwks" metadata parameters from [RFC7591 > ] are used to > convey the client's certificates and public keys, where the X.509 > certificates are represented using the JSON Web Key (JWK) [RFC7517 > ] > "x5c" parameter. Note that Sec 4.7 of RFC 7517 > requires that the key > in the first certificate of the "x5c" parameter must match the publi= c > key represented by other members of the JWK (e.g. "n" and "e" for RS= A, > "x" and "y" for EC). > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------4DBCCE586D39450CE1511984 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks Brian, this makes the spec even better!

I have just this one small note, there seems to be an "and" missing here:

The base64url-encoded value MUST omit all trailing pad=
 '=3D' characters _and_ MUST NOT include any line breaks, whitespace, or =
other additional characters.
Vladimir

On 10/10/18 03:18, Brian Campbell wrote:
A couple of the draft-ietf-oauth-mtls editors recive=
d some off-list
questions and feedback from an implementer, which resulted in a few small=

potential clarifying updates to the document that I think are worth
incorporating despite the post WGLC status.

Barring reasonable objections from the WG or process objections from the
chairs, I'd like to make these updates.

Basically, there were two points of confusion.

First, there was some uncertainty about the order of operations and
encoding steps when computing the "x5t#S256" value.  In order to be more
specific/clear, I propose changing the relevant text in sec 3.1
<https://tools.ietf.org/html/draft=
-ietf-oauth-mtls-11#section-3.1> from:

To represent the hash of a certificate in a JWT, this specification

defines the new JWT Confirmation Method [RFC7800] member "x5t#S256"

for the X.509 Certificate SHA-256 Thumbprint.  The value of the

"x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint,

fingerprint or digest) of the DER encoding of the X.509 certificate

[RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=3D'

characters omitted and without the inclusion of any line breaks,

whitespace, or other additional characters.


to:

To represent the hash of a certificate in a JWT, this specification
defines the new JWT Confirmation Method [RFC7800] member "x5t#S256"
for the X.509 Certificate SHA-256 Thumbprint.  The value of the
"x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash
(a.k.a.
thumbprint, fingerprint or digest) of the DER encoding of the X.509
certificate
[RFC5280]. The base64url-encoded value MUST omit all trailing pad '=3D'
characters
MUST NOT include any line breaks, whitespace, or other additional
characters.


And also, as a way for developers to check their work. to add an example
with a certificate and the "x5t#S256" value for it.

Second was some confusion about matching the cert/key against the keys in=

the client's JWK Set for the self-signed mode. It was said that having so=
me
text to the effect of '(e.g. "n" and "e" for RSA, "x" and "y" for EC)'
along with the text note at the end of Section 2.2.2
<https://tools.ietf.org/html/dra=
ft-ietf-oauth-mtls-11#section-2.2.2>. would
have been helpful. So that paragraph would change from:

   For the Self-Signed Certificate method of binding a certificate to a
   client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC7591
<https://tools.ietf.org/html/rfc7591>] are used to
   convey the client's certificates and public keys, where the X.509
   certificates are represented using the JSON Web Key (JWK) [RFC7517
<https://tools.ietf.org/html/rfc7517>]
   "x5c" parameter (note that Sec 4.7 of RFC 7517
<https://tools.ietf.org/html/rfc7517> requires that the =
key
   in the first certificate of the "x5c" parameter must match the public
   key represented by other members of the JWK).

to:

   For the Self-Signed Certificate method of binding a certificate to a
   client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC7591
<https://tools.ietf.org/html/rfc7591>] are used to
   convey the client's certificates and public keys, where the X.509
   certificates are represented using the JSON Web Key (JWK) [RFC7517
<https://tools.ietf.org/html/rfc7517>]
   "x5c" parameter. Note that Sec 4.7 of RFC 7517
<https://tools.ietf.org/html/rfc7517> requires that the =
key
   in the first certificate of the "x5c" parameter must match the public
   key represented by other members of the JWK (e.g. "n" and "e" for RSA,=

   "x" and "y" for EC).




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

--------------4DBCCE586D39450CE1511984-- --------------ms020702030600060506050501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CygwggU6MIIEIqADAgECAhEA9DW+rlLUzYs+I90AKROPBDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNDIyMDAw MDAwWhcNMTkwNDIyMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd2bGFkaW1pckBjb25uZWN0 MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKRKqCbZFgc5UOwarPfT 8akjZDXcXbV32yOcBnd5Rw1Befh5shhtGy2IWb2DjNHfxNtTe+pRAxd3pMM0b9jV4Bj8St19 sU55RCc3IcE2ZX25sUssusaNFOt9Z9njLjL0mXG5mdZPNomCjYLcx2PGoBlTmkww/MRyOIUg ioYdwghyuCySnZ83natEBgwPosPbUBtgo2FPzzVTFwbAt7I/YBBLoJWcJ0c5TZxJJXjlCK5X HJN5HyTkLE9r1WC6csWg+ImS9Qu1BJrwQmjOADKtVrRnioSWPYXsVeycHHXP00N4qfGps/G4 PoBMebQiJa74m0TF0VoDbcMHXzkbAaFU59ECAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaAFIKv bIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQ/eBsPoW26G+gUAJoWNRvNGOghWzAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcw AoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tMA0GCSqGSIb3DQEB CwUAA4IBAQBc2qNY13iSWIXWU+x+FroixRnfU+aald2oOQ0PCnezrlqkT2Ty/83/S7o6a+uF 1tKlYOu/eSu8lW1vpMIpgsUWE9dTMlsuQ1pDtdss6Di+y5lFl/gZNTJN0itXjI/f5G6LRnUQ 6CLhUgB4GqnhpU5dKORQNvEmBmgyiTD4ZOENcPwalWdRziAYsAkmaINMRPSN+jCjSKS29EFx mremUQ2le6rjruidlSjGxToAj+vbayxXKTo1wifncGDrneuOjQd91HLsrjeUzjwysPXHaELk /sUWs587QWdaDgiuV6hhMNZkuDs5chFl76wdI/faW8o6aznG4gE7ZZWbt9OdonrTMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ4 MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQD0Nb6uUtTNiz4j3QApE48EMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODEwMTMwODUxNTVaMC8GCSqGSIb3DQEJ BDEiBCCQhc7UUHGBaE7J0gaqpJQWles1I92yUM2U7q25IqJ96DBsBgkqhkiG9w0BCQ8xXzBd MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEEAYI3EAQx gbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA 9DW+rlLUzYs+I90AKROPBDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA9DW+rlLUzYs+I90AKROPBDANBgkq hkiG9w0BAQEFAASCAQBz429A6ic5uEoID8oWA9kkkT9FWUbwii3DNVUOMZ1gmql3jN/1Tls2 94HuwQ//+QlP8NiBr//qXmJ5Np9QWLvgu17OwiHpdwShpd64+kWeFl8QvLAWce2dhkt3hemF Wwh/Klt0BjF2dZg6lKTpjuqGvDxwnUN4C87NgwcfC3XeeKyXjlJVBzsdjIyY0WQdQeC0AkxZ 62Td9Fj+mjCVkxS031ReklLMN9IBDYGPV/trpTBTq0Gp4cctH8OqjDBj/2nWkS/1d3PwrBBE 0m0y4CVYR2xXHpGKgdFOLZ02BeFe+t34F87WULGKsKWVw/TS5b+YkRe0EV7e4hUaUBzgQfu3 AAAAAAAA --------------ms020702030600060506050501-- From nobody Sat Oct 13 04:00:03 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A889130E08 for ; Sat, 13 Oct 2018 04:00:01 -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 sQxhQ6AXrH6j for ; Sat, 13 Oct 2018 03:59:59 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C451277C8 for ; Sat, 13 Oct 2018 03:59:58 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id e74-v6so21580750ita.2 for ; Sat, 13 Oct 2018 03:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xhJD9rPG3zO9ORYZgLut4HvKQV5sN/M3RTQqZGezRbI=; b=KZs8OV8kMYyo4t9jCMkYZdHUlCxkyK8eyhtbUR6bi3qTZUFUcV5PUKrCvYnoGobmRg xShNcPIGaOnzLi2BurEvMru5eIVBCdF7GYdv2hoouCHxIqJ1VjlBIIOmDEXVURKJgszN QmaBncZ61uqIcmbAVqivx9bmkjP6ebFtLzClCFUCFCIEAXMRfxGjkrgB4F4qXnRZp833 C2WlR7Rw3o38Ip8d7Pk3wQdBE4vUJkJO3SkuM6U92nwC3uxb9+V+3i1y1Dhw7BtD756o Et+HQMZW2SwsD5Db0IdkMNOqaUPfo/I//UvbqUp/3/nN2pUpfwE57XmQKjXqCt0Ka//W Tgmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xhJD9rPG3zO9ORYZgLut4HvKQV5sN/M3RTQqZGezRbI=; b=dDgEJrMRiwiAy1QnSJYH5tKA5GWuI+hKdNke1Z4SGeJ7gLFGR9tH9chjPSvOWvUZFa DSbjP0um7kRTTXKEf72Yc0C97CvlxpnnJl+eNcivT3gD1N4tCtM3vJKtP3Qyel0yNzx2 jkXxT/5mxO49XGOboC/EZj2+JbGuK//GV+4+N+xLbYjFXfqjtpqNq0cub+TnGZXwO/Fw /TjQo5+LeW8OLDmG3n0QFi0eKTzCmYfnTYTXIn/VsCRsNosRThD8Q/YbnaI/A4ZLfSh8 LISLa/6xqLZS6PsVhalzqgkxiLA9r9+ZK5PVAYKGLCRfPkViHFimxh4OGfanCrPWIsR/ 9ufw== X-Gm-Message-State: ABuFfoi8J77GI8xmKs5UU1UZrl5w8kn9jgIPhD95aX/nkGeQZuz9X7SD KqO5XZjMjb6FcxHh+IXc4cihYjIiTM47DtNe5lrjvNh1PR4= X-Google-Smtp-Source: ACcGV62IqvxFhnkzIjNBz6YM3K+fymnZmf/WbVmrWOdRXO+kBjjZzH7XvBVIaG+nmVqH/ku8nuniz3Yv3BOR/TqYiSA= X-Received: by 2002:a24:9b83:: with SMTP id o125-v6mr6936874itd.165.1539428398052; Sat, 13 Oct 2018 03:59:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Sat, 13 Oct 2018 06:59:46 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000d2bb5b05781a1a18" Archived-At: Subject: Re: [OAUTH-WG] IETF103 OAuth Final Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 11:00:02 -0000 --000000000000d2bb5b05781a1a18 Content-Type: text/plain; charset="UTF-8" All, Here is our updated agenda: https://datatracker.ietf.org/doc/agenda-103-oauth/ *Notice that the first session is now on Monday morning, instead of Tuesday morning.* 9:00-11:00 *Monday *Morning session I Chairs Update 10min Torsten Lodderstedt - draft-ietf-oauth-security-topics 30min - draft-ietf-oauth-jwt-introspection-response 30min - openid-financial-api-jarm-wd 15min Hannes Tschofenig - draft-ietf-oauth-pop-key-distribution 20min Omer Levi Hevroni (remote) - draft-hevroni-oauth-seamless-flow 15min 11:20-12:20 *Tuesday *Morning session II Brian Campbell - draft-ietf-oauth-resource-indicators 15min - draft-ietf-oauth-token-binding 15min - draft-ietf-oauth-mtls 5min - draft-ietf-oauth-token-exchange 5min Dick Hardt - draft-ietf-oauth-reciprocal 10min - draft-hardt-oauth-distributed 10min Regards, Rifaat & Hannes On Fri, Oct 12, 2018 at 1:25 PM Rifaat Shekh-Yusef wrote: > All, > > Here is our final agenda for Bangkok: > https://datatracker.ietf.org/meeting/103/materials/agenda-103-oauth-02 > > 9:00-11:00 Tuesday Morning session I > > Chairs Update 10min > > Torsten Lodderstedt > - draft-ietf-oauth-security-topics 30min > - draft-ietf-oauth-jwt-introspection-response 30min > - openid-financial-api-jarm-wd 15min > > Hannes Tschofenig > - draft-ietf-oauth-pop-key-distribution 20min > > Omer Levi Hevroni (remote) > - draft-hevroni-oauth-seamless-flow 15min > > > 11:20-12:20 Tuesday Morning session II > > Brian Campbell > - draft-ietf-oauth-resource-indicators 20min > - draft-ietf-oauth-token-binding 20min > - draft-ietf-oauth-mtls 10min > - draft-ietf-oauth-token-exchange 10min > > > Regards, > > Rifaat & Hannes > > > --000000000000d2bb5b05781a1a18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Notice that the first session is now on Monday morning= , instead of Tuesday morning.

9:00-11:00=
	Monday Morning session I

Chairs Update                                       10min

Torsten Lodderstedt
- draft-ietf-oauth-security-topics                  30min
- draft-ietf-oauth-jwt-introspection-response       30min
- openid-financial-api-jarm-wd                      15min

Hannes Tschofenig
 - draft-ietf-oauth-pop-key-distribution            20min

Omer Levi Hevroni (remote)
- draft-hevroni-oauth-seamless-flow                 15min


11:20-12:20	Tuesday Morning session II

Brian Campbell
- draft-ietf-oauth-resource-indicators              15min
- draft-ietf-oauth-token-binding                    15min
- draft-ietf-oauth-mtls                             5min
- draft-ietf-oauth-token-exchange                   5min

Dick Hardt
- draft-ietf-oauth-reciprocal                       10min
- draft-hardt-oauth-distributed                     10min
Regards,
=C2=A0Rifaat & Hannes



On F= ri, Oct 12, 2018 at 1:25 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

Here is our final agenda f= or Bangkok:
9:00-11:00	Tuesday Morning session I

Chairs Update                                       10min

Torsten Lodderstedt
- draft-ietf-oauth-security-topics                  30min
- draft-ietf-oauth-jwt-introspection-response       30min
- openid-financial-api-jarm-wd                      15min

Hannes Tschofenig
 - draft-ietf-oauth-pop-key-distribution            20min

Omer Levi Hevroni (remote)
- draft-hevroni-oauth-seamless-flow                 15min


11:20-12:20	Tuesday Morning session II

Brian Campbell
- draft-ietf-oauth-resource-indicators              20min
- draft-ietf-oauth-token-binding                    20min
- draft-ietf-oauth-mtls                             10min
- draft-ietf-oauth-token-exchange                   10min

<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">Re= gards,
 Rifaat & Hannes

--000000000000d2bb5b05781a1a18-- From nobody Sat Oct 13 05:43:01 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FFB130DF5 for ; Sat, 13 Oct 2018 05:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEsz65tMM0L1 for ; Sat, 13 Oct 2018 05:42:56 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60119130E14 for ; Sat, 13 Oct 2018 05:42:56 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id w200-v6so21762103itc.4 for ; Sat, 13 Oct 2018 05:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=imWfIISb5ZgQFxkENd+o4hgRiwL0IVkROPGUOt8+qcI=; b=AMGdUNddGkaJwV0YeYl656bK4hNtfJAR24wbs3rBqXyFYcWb09wcOwOXsuC/ive+8D T8Du0UZj/wEMNf/gr2AOcS/2DHKG3VTZtlu2g15MMdnABLiGotG9vaN5pF5LZD0i/b8f 6M/kWsyAORFDbJ+eN6v4JpMHzeZQxXmQDYOdo= 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=imWfIISb5ZgQFxkENd+o4hgRiwL0IVkROPGUOt8+qcI=; b=arFXXMTG9a37cmR5kd6m43fA1AIeevBX2j7mfO5Gxz0nLsi92dlEFgwfqOZk7Em5OW Ljin5FBxlqig23fFOpsLMil8ydTJKVVW+ZLa3BSbx4qGpstWc+tiQssjfij2/fDE/zNg AO0l97DqPE/W/mJNpHIC9num4tHJkBuh7keqeeZt8p32R7i/m9jHQsLR5R4DJFuK4yOl XVdwnRaPcv4JNN0yxVj6R3G4jU0LH3azfJVNSJLkVcyYBBaSjAxHHIybRsqgHm1Op8Mn 6JJ/ZPIgySuaTN0X9f8ytP18J4/25wiSLo4PSLhVG3mPIx4y2EF7UiVTv3soVbM26CVJ Ndcw== X-Gm-Message-State: ABuFfojs5jIs46TbU6QU8g1DSskKk4gbjaRxL+seVdW4cMeqKa4Z5eLf AC7cXUdfxZPwqWC44adIeE0h0WvMcrWkKfyvuFv1RMxXrMzgCpwAybU5j02rUE4JFveZHqjGuPf 7lnYf/atyMcJKkqX4pyI= X-Google-Smtp-Source: ACcGV63DIw1lDHSi3F9JyITqQfsOB9R8KsqCdD3d2e07ORxCbgKGMpCCBUfYN+FAceb9TA9Zs2n49A4M0lNGRlveLO4= X-Received: by 2002:a24:6882:: with SMTP id v124-v6mr7429712itb.124.1539434575432; Sat, 13 Oct 2018 05:42:55 -0700 (PDT) MIME-Version: 1.0 References: <4d27c396-24f4-4649-0585-826ff9ce1dbf@connect2id.com> In-Reply-To: <4d27c396-24f4-4649-0585-826ff9ce1dbf@connect2id.com> From: Brian Campbell Date: Sat, 13 Oct 2018 06:42:28 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="000000000000062e7d05781b8b33" Archived-At: Subject: Re: [OAUTH-WG] late off-list developer feedback on OAuth MTLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 12:42:59 -0000 --000000000000062e7d05781b8b33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good catch, Vladimir. Thanks! On Sat, Oct 13, 2018 at 2:52 AM Vladimir Dzhuvinov wrote: > Thanks Brian, this makes the spec even better! > > I have just this one small note, there seems to be an "and" missing here: > > The base64url-encoded value MUST omit all trailing pad '=3D' characters _= and_ MUST NOT include any line breaks, whitespace, or other additional char= acters. > > Vladimir > > On 10/10/18 03:18, Brian Campbell wrote: > > A couple of the draft-ietf-oauth-mtls editors recived some off-list > questions and feedback from an implementer, which resulted in a few small > potential clarifying updates to the document that I think are worth > incorporating despite the post WGLC status. > > Barring reasonable objections from the WG or process objections from the > chairs, I'd like to make these updates. > > Basically, there were two points of confusion. > > First, there was some uncertainty about the order of operations and > encoding steps when computing the "x5t#S256" value. In order to be more > specific/clear, I propose changing the relevant text in sec 3.1 from: > > To represent the hash of a certificate in a JWT, this specification > > defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" > > for the X.509 Certificate SHA-256 Thumbprint. The value of the > > "x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint, > > fingerprint or digest) of the DER encoding of the X.509 certificate > > [RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=3D' > > characters omitted and without the inclusion of any line breaks, > > whitespace, or other additional characters. > > > to: > > To represent the hash of a certificate in a JWT, this specification > defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" > for the X.509 Certificate SHA-256 Thumbprint. The value of the > "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash > (a.k.a. > thumbprint, fingerprint or digest) of the DER encoding of the X.509 > certificate > [RFC5280]. The base64url-encoded value MUST omit all trailing pad '=3D' > characters > MUST NOT include any line breaks, whitespace, or other additional > characters. > > > And also, as a way for developers to check their work. to add an example > with a certificate and the "x5t#S256" value for it. > > Second was some confusion about matching the cert/key against the keys in > the client's JWK Set for the self-signed mode. It was said that having so= me > text to the effect of '(e.g. "n" and "e" for RSA, "x" and "y" for EC)' > along with the text note at the end of Section 2.2.2 . would > have been helpful. So that paragraph would change from: > > For the Self-Signed Certificate method of binding a certificate to a > client using mutual TLS client authentication, the existing > "jwks_uri" or "jwks" metadata parameters from [RFC7591 ] are used to > convey the client's certificates and public keys, where the X.509 > certificates are represented using the JSON Web Key (JWK) [RFC7517 ] > "x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key > in the first certificate of the "x5c" parameter must match the public > key represented by other members of the JWK). > > to: > > For the Self-Signed Certificate method of binding a certificate to a > client using mutual TLS client authentication, the existing > "jwks_uri" or "jwks" metadata parameters from [RFC7591 ] are used to > convey the client's certificates and public keys, where the X.509 > certificates are represented using the JSON Web Key (JWK) [RFC7517 ] > "x5c" parameter. Note that Sec 4.7 of RFC 7517 requires that the key > in the first certificate of the "x5c" parameter must match the public > key represented by other members of the JWK (e.g. "n" and "e" for RSA, > "x" and "y" for EC). > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000062e7d05781b8b33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good catch, Vladimir. Thanks!
<= /div>
On Sat, Oct 13, 2018 a= t 2:52 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20

Thanks Brian, this makes the spec even better!

I have just this one small note, there seems to be an "and"= ; missing here:

The base64url-encoded value MUST omit all trailing pad '=3D=
9; characters _and_ MUST NOT include any line breaks, whitespace, or other =
additional characters.
Vladimir

On 10/10/18 03:18, = Brian Campbell wrote:
A couple of the draft-ietf-oauth-mtls editors recived some off-l=
ist
questions and feedback from an implementer, which resulted in a few small
potential clarifying updates to the document that I think are worth
incorporating despite the post WGLC status.

Barring reasonable objections from the WG or process objections from the
chairs, I'd like to make these updates.

Basically, there were two points of confusion.

First, there was some uncertainty about the order of operations and
encoding steps when computing the "x5t#S256" value.  In order to =
be more
specific/clear, I propose changing the relevant text in sec 3.1
&l=
t;https://tools.ietf.org/html/draft-ietf-oauth-mtls-11#section-3.1> =
from:

To represent the hash of a certificate in a JWT, this specification

defines the new JWT Confirmation Method [RFC7800] member "x5t#S256&quo=
t;

for the X.509 Certificate SHA-256 Thumbprint.  The value of the

"x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint,

fingerprint or digest) of the DER encoding of the X.509 certificate

[RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=3D&#=
39;

characters omitted and without the inclusion of any line breaks,

whitespace, or other additional characters.


to:

To represent the hash of a certificate in a JWT, this specification
defines the new JWT Confirmation Method [RFC7800] member "x5t#S256&quo=
t;
for the X.509 Certificate SHA-256 Thumbprint.  The value of the
"x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] =
hash
(a.k.a.
thumbprint, fingerprint or digest) of the DER encoding of the X.509
certificate
[RFC5280]. The base64url-encoded value MUST omit all trailing pad '=3D&=
#39;
characters
MUST NOT include any line breaks, whitespace, or other additional
characters.


And also, as a way for developers to check their work. to add an example
with a certificate and the "x5t#S256" value for it.

Second was some confusion about matching the cert/key against the keys in
the client's JWK Set for the self-signed mode. It was said that having =
some
text to the effect of '(e.g. "n" and "e" for RSA, &=
quot;x" and "y" for EC)'
along with the text note at the end of Section 2.2.2
=
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-11#section-2.2.2><=
/a>. would
have been helpful. So that paragraph would change from:

   For the Self-Signed Certificate method of binding a certificate to a
   client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC75=
91
<https://tools.ietf.org/html=
/rfc7591>] are used to
   convey the client's certificates and public keys, where the X.509
   certificates are represented using the JSON Web Key (JWK) [RFC7517
<https://tools.ietf.org/html=
/rfc7517>]
   "x5c" parameter (note that Sec 4.7 of RFC 7517
<https://tools.ietf.org/html=
/rfc7517> requires that the key
   in the first certificate of the "x5c" parameter must match the=
 public
   key represented by other members of the JWK).

to:

   For the Self-Signed Certificate method of binding a certificate to a
   client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC75=
91
<https://tools.ietf.org/html=
/rfc7591>] are used to
   convey the client's certificates and public keys, where the X.509
   certificates are represented using the JSON Web Key (JWK) [RFC7517
<https://tools.ietf.org/html=
/rfc7517>]
   "x5c" parameter. Note that Sec 4.7 of RFC 7517
<https://tools.ietf.org/html=
/rfc7517> requires that the key
   in the first certificate of the "x5c" parameter must match the=
 public
   key represented by other members of the JWK (e.g. "n" and &quo=
t;e" for RSA,
   "x" and "y" for EC).




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/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. --000000000000062e7d05781b8b33-- From nobody Mon Oct 15 05:50:08 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A342130E4D; Mon, 15 Oct 2018 05:50:06 -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.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153960780651.19474.15239326265214828055@ietfa.amsl.com> Date: Mon, 15 Oct 2018 05:50:06 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 12:50:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Security Best Current Practice Authors : Torsten Lodderstedt John Bradley Andrey Labunets Daniel Fett Filename : draft-ietf-oauth-security-topics-08.txt Pages : 34 Date : 2018-10-15 Abstract: This document describes best current security practices for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-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 Mon Oct 15 05:55:47 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93C5130E63 for ; Mon, 15 Oct 2018 05:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBoGc0StU8xQ for ; Mon, 15 Oct 2018 05:55:42 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.98]) (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 A4F07130E4D for ; Mon, 15 Oct 2018 05:55:42 -0700 (PDT) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gC2PM-000089-2h for oauth@ietf.org; Mon, 15 Oct 2018 14:55:40 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_4B85726F-D327-4EF5-802C-0943863EF2D3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 15 Oct 2018 14:55:34 +0200 References: <153960780651.19474.15239326265214828055@ietfa.amsl.com> To: oauth In-Reply-To: <153960780651.19474.15239326265214828055@ietfa.amsl.com> Message-Id: <460FFB99-0AE8-41D8-B324-0E180C86FF26@lodderstedt.net> X-Mailer: Apple Mail (2.3445.9.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 12:55:46 -0000 --Apple-Mail=_4B85726F-D327-4EF5-802C-0943863EF2D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, the new revision has an additional section 2.1.2 giving recommendations = on token replay/injection detection with the implicit grant. = Additionally, we also uppercased the relevant keywords in section 2 to = comply with RFC 2119. Looking forward for your feedback.=20 kind regards, Torsten.=20 > Am 15.10.2018 um 14:50 schrieb internet-drafts@ietf.org: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename : draft-ietf-oauth-security-topics-08.txt > Pages : 34 > Date : 2018-10-15 >=20 > Abstract: > This document describes best current security practices for OAuth > 2.0. It updates and extends the OAuth 2.0 Security Threat Model to > incorporate practical experiences gathered since OAuth 2.0 was > published and covers new threats relevant due to the broader > application of OAuth 2.0. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-08 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4B85726F-D327-4EF5-802C-0943863EF2D3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgxMDE1MTI1NTM1WjAjBgkqhkiG9w0BCQQxFgQU9Xf3XTLw5hSr DoqALP6RlQDpZDgwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAE0JtCQsp0yqBIvJVJ3J6Pd+3aifOyw6Z5dOsAq69rYiwHKbcYIN 4aDwKHkTd1rFIPQbswYn9bA39a/fcOruJdkb12ak/kvybSGD45JZqVK7tBKsldWjl5mocYzwH6dx 8hhTVkwE+WOa68T45vUdpKI0apienOW04/x+OMDYwq0Y1v0Z1ZRu3hiph2+gEsZBf2K5aGlvEiki aXVzAEfekir2N259SeaViAX7p29bHQmFNm4f9tyXm6mGRyJCZjj7JRKN5vZKvYMCTz3lr2O1rIpn YKNovuyAA0lwj9QaNFTTR/qiRvh6mACeaOrWlXEJkPKT2yjBxhklfD2v+ZEfxcoAAAAAAAA= --Apple-Mail=_4B85726F-D327-4EF5-802C-0943863EF2D3-- From nobody Thu Oct 18 03:34:53 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D67E130E44; Thu, 18 Oct 2018 03:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 0d1T-92kteXO; Thu, 18 Oct 2018 03:34:43 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 34BD1130DFC; Thu, 18 Oct 2018 03:34:43 -0700 (PDT) Received: from nb-10688.ethz.ch ([82.130.103.20]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpa id 1gD5dX-0000el-Sa; Thu, 18 Oct 2018 12:34:39 +0200 To: William Denniss Cc: Rifaat Shekh-Yusef , oauth , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-device-flow@ietf.org References: <153245825559.22685.11395607099141261021.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind_=28IETF=29?= Message-ID: Date: Thu, 18 Oct 2018 12:34:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A3EB29A29CC992F238632CA6" Content-Language: en-US X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1539858883;c117486e; X-HE-SMSGID: 1gD5dX-0000el-Sa Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-i?= =?utf-8?q?etf-oauth-device-flow-11=3A_=28with_DISCUSS=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 10:34:47 -0000 This is a multi-part message in MIME format. --------------A3EB29A29CC992F238632CA6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi William, sorry for my very late reply. I must have missed this update and just finally some had time to look through my open discusses. Thanks for addressing my comments quickly and adequately; I just cleared my discuss. Regarding the last point below, I think if that is an optimization the MAY is okay. Thanks and sorry again for the late response! Mirja On 02.08.18 02:24, William Denniss wrote: > Mirja, > > Thanks for your feedback. Version 12 has been posted which > incorporates much of your feedback. Replies inline: > > On Tue, Jul 24, 2018 at 11:50 AM, Mirja Kühlewind > wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Please specify more clearly the (default) polling behavior to > ensure that the > polling does neither overload the network, nor the server, or is never > terminated. Ideally provide default values and an upper bound for > the polling > frequency, as well as a timer to terminate polling if no reply is > received (and > no expiration time is given). See further details below. > > 1) Sec 3.3: "until the user completes the interaction, the code > expires, or > another >    error occurs." > What if not expiration time is given (as this optional) and no > reply is ever > received? > > > The expiration time is now required. > > > 2) Sec 3.5: "the client should stop polling and react accordingly, for >    example, by displaying an error to the user." > Maybe: > "the client MUST stop polling and SHOULD react accordingly, for >    example, by displaying an error to the user." > > > Added, thanks! > > 3) sec 3.5 "If no interval was provided, the client >    MUST use a reasonable default polling interval." > Can you please provide a default number for a "reasonable" polling > interval! > And in best case an upper bound! > > > We set a default of 5 seconds. > > > 4) sec 3.5: "...increasing the time between polls if a >    "slow_down" error is received. " > Maybe use a separate normative sentence instead: > "The client SHOUD increase the time between polls if a >    "slow_down" error is received." > Or MUST? If so how much? Can you given further (default) guidance. > > > We now document that every slow_down message should increase the > interval by 5 seconds. > > > 5) sec 3.5: "Clients MAY then choose to >    start a new device authorization session." > Maybe make it clear that polling is stopped > "Clients MUST stop polling but MAY then choose to >    start a new device authorization session." > > > This was revised, thank you! > > > 6) sec 3.5: "then the >    device MAY wait until notified on that channel that the user has >    completed the action before initiating the token request." > Why not SHOULD (or MUST) here? > > > This is a non-normative discussion of a potential optimization, > perhaps we should drop the normative keyword completely? > > The reason MAY was chosen is that the client would be free to follow > the rest of this document which allows for polling. > > Best, > William > --------------A3EB29A29CC992F238632CA6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi William,

sorry for my very late reply. I must have missed this update and just finally some had time to look through my open discusses. Thanks for addressing my comments quickly and adequately; I just cleared my discuss.

Regarding the last point below, I think if that is an optimization the MAY is okay.

Thanks and sorry again for the late response!
Mirja



On 02.08.18 02:24, William Denniss wrote:
Mirja,

Thanks for your feedback. Version 12 has been posted which incorporates much of your feedback. Replies inline:

On Tue, Jul 24, 2018 at 11:50 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please specify more clearly the (default) polling behavior to ensure that the
polling does neither overload the network, nor the server, or is never
terminated. Ideally provide default values and an upper bound for the polling
frequency, as well as a timer to terminate polling if no reply is received (and
no expiration time is given). See further details below.

1) Sec 3.3: "until the user completes the interaction, the code expires, or
another
   error occurs."
What if not expiration time is given (as this optional) and no reply is ever
received?

The expiration time is now required.
 

2) Sec 3.5: "the client should stop polling and react accordingly, for
   example, by displaying an error to the user."
Maybe:
"the client MUST stop polling and SHOULD react accordingly, for
   example, by displaying an error to the user."


Added, thanks!
 
3) sec 3.5 "If no interval was provided, the client
   MUST use a reasonable default polling interval."
Can you please provide a default number for a "reasonable" polling interval!
And in best case an upper bound!

We set a default of 5 seconds.
 

4) sec 3.5: "...increasing the time between polls if a
   "slow_down" error is received. "
Maybe use a separate normative sentence instead:
"The client SHOUD increase the time between polls if a
   "slow_down" error is received."
Or MUST? If so how much? Can you given further (default) guidance.

We now document that every slow_down message should increase the interval by 5 seconds.
 

5) sec 3.5: "Clients MAY then choose to
   start a new device authorization session."
Maybe make it clear that polling is stopped
"Clients MUST stop polling but MAY then choose to
   start a new device authorization session."

This was revised, thank you!
 

6) sec 3.5: "then the
   device MAY wait until notified on that channel that the user has
   completed the action before initiating the token request."
Why not SHOULD (or MUST) here?

This is a non-normative discussion of a potential optimization, perhaps we should drop the normative keyword completely?

The reason MAY was chosen is that the client would be free to follow the rest of this document which allows for polling.

Best,
William
 


--------------A3EB29A29CC992F238632CA6-- From nobody Thu Oct 18 08:27:21 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 863A5128CB7; Thu, 18 Oct 2018 08:27: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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153987643949.22265.11244050170724917787@ietfa.amsl.com> Date: Thu, 18 Oct 2018 08:27:19 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 15:27: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 WG of the IETF. Title : OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-12.txt Pages : 23 Date : 2018-10-18 Abstract: This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-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 Thu Oct 18 08:32:08 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AC212D4E8 for ; Thu, 18 Oct 2018 08:32:06 -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 WdRUTGRTYE4e for ; Thu, 18 Oct 2018 08:32:03 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 7DDCC129619 for ; Thu, 18 Oct 2018 08:32:02 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id l25-v6so21209820ioj.0 for ; Thu, 18 Oct 2018 08:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n8zfm/S7DVx7h9BGamREN3XiNa0rc9Dkqr3ARguxsMw=; b=eCQZeNGnG6yRfAQRBWADx9EE2dS6axCYAtm8PWyLbSz1ousFlVzUaS3/edxCYY6SEG mIeZz34BIDSSi5pe+MuRhozNz+vDJVdDv+eeKs9nfnq60+lEFkeolWk4V524GnBsh087 mJi9TrVIDky6kIVWH6kUrbNK9ea9fUMT2baYk= 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=n8zfm/S7DVx7h9BGamREN3XiNa0rc9Dkqr3ARguxsMw=; b=i68Iq5wyK/UfBc7cAiAszWw05WmNupVheNiD8VeIVFy7a3RLGM4FpLagW1wtVhLwRN L0yimTxMho71KSSh5BPB6sAGf8Y6m+UKeA4DCueMPJ8h84j3eo42XifUv9ZfoZfYHrWP XwL+fPLgMars17MAs+JYkHONUDjcK/snDJMcb7P9wtKitap53KO7zhC5WyOnFKhKwK7l BUHmxQXzcWD9Nf6MKxlNuG4yQ0pPdC+9rwVZ87c35KE7MIQTZqO9/n/rHseR9CgxpZxA I2SdCEI85+FIw1A+ozt3tg2hGvy1qVYuEX3KB4NkuNqnPjRRF0yclHZZdmoWbNVsCHi6 qFaA== X-Gm-Message-State: AGRZ1gKhRe31oIx132BmEKlnfYFNLlKIWMpvh6lVtNKjCPOE43ECXtQ7 slVG7s/tc/8Tkc+mfyfsBbVdUCiv4d+dOJydkK8at3m/mRjQf9dto/OHj4T9LLZLshu1D9q/iom 94OVxO8oaijVtFYK6UC8= X-Google-Smtp-Source: AJdET5cv8zz21kXPWsaZPlNidmhTpo2KzvYS3QMSNCwa0OvdFIYA1Y1a/yMjxyy2voMnltBeiMOIQjmpgyYJnqZnLLs= X-Received: by 2002:a6b:7104:: with SMTP id q4-v6mr488018iog.138.1539876721504; Thu, 18 Oct 2018 08:32:01 -0700 (PDT) MIME-Version: 1.0 References: <4d27c396-24f4-4649-0585-826ff9ce1dbf@connect2id.com> In-Reply-To: From: Brian Campbell Date: Thu, 18 Oct 2018 09:31:35 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="000000000000fc134d0578827c89" Archived-At: Subject: Re: [OAUTH-WG] late off-list developer feedback on OAuth MTLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 15:32:06 -0000 --000000000000fc134d0578827c89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable These changes have been made in the just published -12 draft. The diff is viewable at https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-12 Thanks all! On Sat, Oct 13, 2018 at 6:42 AM Brian Campbell wrote: > Good catch, Vladimir. Thanks! > > On Sat, Oct 13, 2018 at 2:52 AM Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > >> Thanks Brian, this makes the spec even better! >> >> I have just this one small note, there seems to be an "and" missing here= : >> >> The base64url-encoded value MUST omit all trailing pad '=3D' characters = _and_ MUST NOT include any line breaks, whitespace, or other additional cha= racters. >> >> Vladimir >> >> On 10/10/18 03:18, Brian Campbell wrote: >> >> A couple of the draft-ietf-oauth-mtls editors recived some off-list >> questions and feedback from an implementer, which resulted in a few smal= l >> potential clarifying updates to the document that I think are worth >> incorporating despite the post WGLC status. >> >> Barring reasonable objections from the WG or process objections from the >> chairs, I'd like to make these updates. >> >> Basically, there were two points of confusion. >> >> First, there was some uncertainty about the order of operations and >> encoding steps when computing the "x5t#S256" value. In order to be more >> specific/clear, I propose changing the relevant text in sec 3.1 from: >> >> To represent the hash of a certificate in a JWT, this specification >> >> defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" >> >> for the X.509 Certificate SHA-256 Thumbprint. The value of the >> >> "x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint, >> >> fingerprint or digest) of the DER encoding of the X.509 certificate >> >> [RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=3D' >> >> characters omitted and without the inclusion of any line breaks, >> >> whitespace, or other additional characters. >> >> >> to: >> >> To represent the hash of a certificate in a JWT, this specification >> defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" >> for the X.509 Certificate SHA-256 Thumbprint. The value of the >> "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash >> (a.k.a. >> thumbprint, fingerprint or digest) of the DER encoding of the X.509 >> certificate >> [RFC5280]. The base64url-encoded value MUST omit all trailing pad '=3D' >> characters >> MUST NOT include any line breaks, whitespace, or other additional >> characters. >> >> >> And also, as a way for developers to check their work. to add an example >> with a certificate and the "x5t#S256" value for it. >> >> Second was some confusion about matching the cert/key against the keys i= n >> the client's JWK Set for the self-signed mode. It was said that having s= ome >> text to the effect of '(e.g. "n" and "e" for RSA, "x" and "y" for EC)' >> along with the text note at the end of Section 2.2.2 . would >> have been helpful. So that paragraph would change from: >> >> For the Self-Signed Certificate method of binding a certificate to a >> client using mutual TLS client authentication, the existing >> "jwks_uri" or "jwks" metadata parameters from [RFC7591 ] are used to >> convey the client's certificates and public keys, where the X.509 >> certificates are represented using the JSON Web Key (JWK) [RFC7517 ] >> "x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key >> in the first certificate of the "x5c" parameter must match the public >> key represented by other members of the JWK). >> >> to: >> >> For the Self-Signed Certificate method of binding a certificate to a >> client using mutual TLS client authentication, the existing >> "jwks_uri" or "jwks" metadata parameters from [RFC7591 ] are used to >> convey the client's certificates and public keys, where the X.509 >> certificates are represented using the JSON Web Key (JWK) [RFC7517 ] >> "x5c" parameter. Note that Sec 4.7 of RFC 7517 requires that the key >> in the first certificate of the "x5c" parameter must match the public >> key represented by other members of the JWK (e.g. "n" and "e" for RSA= , >> "x" and "y" for EC). >> >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000fc134d0578827c89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These changes have been made in the = just published -12 draft.


On Sat, Oct 13, 2018 at 6:42 AM Brian Campbel= l <bcampbell@pingidentity.= com> wrote:
Good catch, Vladimir. Thanks!

On Sat, Oct 13, 2018 at 2:52 AM Vladim= ir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20

Thanks Brian, this makes the spec even better!

I have just this one small note, there seems to be an "and"= ; missing here:

The base64url-encoded value MUST omit all trailing pad '=3D=
9; characters _and_ MUST NOT include any line breaks, whitespace, or other =
additional characters.
Vladimir

On 10/10/18 03:18, Brian Campbell wrote:
A couple of the draft-ietf-oauth-mtls editors recived some off-l=
ist
questions and feedback from an implementer, which resulted in a few small
potential clarifying updates to the document that I think are worth
incorporating despite the post WGLC status.

Barring reasonable objections from the WG or process objections from the
chairs, I'd like to make these updates.

Basically, there were two points of confusion.

First, there was some uncertainty about the order of operations and
encoding steps when computing the "x5t#S256" value.  In order to =
be more
specific/clear, I propose changing the relevant text in sec 3.1
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-1=
1#section-3.1> from:

To represent the hash of a certificate in a JWT, this specification

defines the new JWT Confirmation Method [RFC7800] member "x5t#S256&quo=
t;

for the X.509 Certificate SHA-256 Thumbprint.  The value of the

"x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint,

fingerprint or digest) of the DER encoding of the X.509 certificate

[RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=3D&#=
39;

characters omitted and without the inclusion of any line breaks,

whitespace, or other additional characters.


to:

To represent the hash of a certificate in a JWT, this specification
defines the new JWT Confirmation Method [RFC7800] member "x5t#S256&quo=
t;
for the X.509 Certificate SHA-256 Thumbprint.  The value of the
"x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] =
hash
(a.k.a.
thumbprint, fingerprint or digest) of the DER encoding of the X.509
certificate
[RFC5280]. The base64url-encoded value MUST omit all trailing pad '=3D&=
#39;
characters
MUST NOT include any line breaks, whitespace, or other additional
characters.


And also, as a way for developers to check their work. to add an example
with a certificate and the "x5t#S256" value for it.

Second was some confusion about matching the cert/key against the keys in
the client's JWK Set for the self-signed mode. It was said that having =
some
text to the effect of '(e.g. "n" and "e" for RSA, &=
quot;x" and "y" for EC)'
along with the text note at the end of Section 2.2.2
<https://tools.ietf.org/html/draft-ietf-oauth-mtls=
-11#section-2.2.2>. would
have been helpful. So that paragraph would change from:

   For the Self-Signed Certificate method of binding a certificate to a
   client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC75=
91
<https=
://tools.ietf.org/html/rfc7591>] are used to
   convey the client's certificates and public keys, where the X.509
   certificates are represented using the JSON Web Key (JWK) [RFC7517
<https=
://tools.ietf.org/html/rfc7517>]
   "x5c" parameter (note that Sec 4.7 of RFC 7517
<https=
://tools.ietf.org/html/rfc7517> requires that the key
   in the first certificate of the "x5c" parameter must match the=
 public
   key represented by other members of the JWK).

to:

   For the Self-Signed Certificate method of binding a certificate to a
   client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC75=
91
<https=
://tools.ietf.org/html/rfc7591>] are used to
   convey the client's certificates and public keys, where the X.509
   certificates are represented using the JSON Web Key (JWK) [RFC7517
<https=
://tools.ietf.org/html/rfc7517>]
   "x5c" parameter. Note that Sec 4.7 of RFC 7517
<https=
://tools.ietf.org/html/rfc7517> requires that the key
   in the first certificate of the "x5c" parameter must match the=
 public
   key represented by other members of the JWK (e.g. "n" and &quo=
t;e" for RSA,
   "x" and "y" for EC).




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

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

<= 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. --000000000000fc134d0578827c89-- From nobody Thu Oct 18 11:00:21 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7B9130DF5; Thu, 18 Oct 2018 11:00:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef To: X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Hannes Tschofenig , hannes.tschofenig@arm.com, iesg-secretary@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Message-ID: <153988561363.22204.10263157052302032449.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2018 11:00:13 -0700 Archived-At: Subject: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-jwt-bcp-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 18:00:20 -0000 Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-jwt-bcp-03 as Best Current Practice on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ From nobody Fri Oct 19 05:11:19 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E4B128B14; Fri, 19 Oct 2018 05:11:10 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153995107083.31761.7910294490450307359@ietfa.amsl.com> Date: Fri, 19 Oct 2018 05:11:10 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 12:11:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones Brian Campbell John Bradley William Denniss Filename : draft-ietf-oauth-token-binding-08.txt Pages : 30 Date : 2018-10-19 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client Authentication. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-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 Oct 19 05:19:52 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D268130E7B for ; Fri, 19 Oct 2018 05:19:50 -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 TWZmIvZa3IDk for ; Fri, 19 Oct 2018 05:19:47 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE56130DEC for ; Fri, 19 Oct 2018 05:19:47 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id m15so4197014itl.4 for ; Fri, 19 Oct 2018 05:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cqejVkNpGqkLcsTNqWJ2kdZ9rrd4BhvgVrtMSAFMmz4=; b=DoOi6+RQzs3uINUrwaets0tdYNZD8a1WgNlSDIEQOFsZnZ3eNBpEBU3rIsLMG4Gxnq Ca1ipgTGGhWeFFjB1s/+pEHMo3ju6YppZ9/HmXb68u+pfcIytsIwm6z5fxcV+ZXgazoH hhZ3v6rs7nFzGl3D/VgTg7i9fMiHOqUYx/iBQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cqejVkNpGqkLcsTNqWJ2kdZ9rrd4BhvgVrtMSAFMmz4=; b=hMOuoGqNAPaTUCoYsmYZEaTRQY/4qgEERKTz8bY1zktz1qJED3GHfyk66Ex2X8VmkW cMFsIq//uDyCCFmkaYKl7tWwOQuk4QZemPJdQvSkISamniVuxZnQv0VkkjT2aSYUWuz9 lkW3J7wBaSAcvmcbZmTfO079HiUg0rFNgbRukaGmu4/IQNpIpkqsxhXoYtgyJbhjdHKm njiine8FvJk/EOF+us2xnRSuNmR1G7SYT8fKyZxkMnT1tgLklHJ/QEYnOuc5CAD8Z5gp RX0dCEMpNTenoqBy780F6qzKiBfbMEmFk8i2najgeKdEuqAYbEpMSp/TLwzCSyJBX28o Y3Hw== X-Gm-Message-State: ABuFfojS2KfcQ+SvUv8LDNB6ixPUZ7xQ3kilke2J0556Qr/e+bXz6PMr MdIbbTDRaW4XjqZoxT0l0/icaIGIlNxLhO5JzgyxPjT6uvr1PjbTeYMuUy1kFGuyqXRfWR1r8p+ m7bS5ePfGiepb2fGt9j4= X-Google-Smtp-Source: ACcGV63dJc0gs9EBYpuSIxcIj1DSKz0UE8l2vRtojY868XCjzOel6KUmS2U8Laurg1/vG3x/ZZv1n9Ss4KC3zvESqMg= X-Received: by 2002:a24:fc02:: with SMTP id b2-v6mr2863464ith.45.1539951586328; Fri, 19 Oct 2018 05:19:46 -0700 (PDT) MIME-Version: 1.0 References: <153995107083.31761.7910294490450307359@ietfa.amsl.com> In-Reply-To: <153995107083.31761.7910294490450307359@ietfa.amsl.com> From: Brian Campbell Date: Fri, 19 Oct 2018 06:19:19 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000465e26057893eb3b" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-binding-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 12:19:51 -0000 --000000000000465e26057893eb3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This minor draft revision updates some references and expands the Acknowledgements a bit. -08 o Update reference to -03 of openid-connect-token-bound- authentication. o Update the references to the core token binding specs, which are now RFCs. o Update reference to AS metadata, which is now RFC. o Add chairs and ADs to the Acknowledgements. ---------- Forwarded message --------- From: Date: Fri, Oct 19, 2018 at 6:12 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-08.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones Brian Campbell John Bradley William Denniss Filename : draft-ietf-oauth-token-binding-08.txt Pages : 30 Date : 2018-10-19 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client Authentication. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-binding-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000465e26057893eb3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This minor draft re= vision updates some references and expands the Acknowledgements a bit.
= 
-08
o  Update reference to=
 -03 of openid-connect-token-bound-
   authentication.
o  Update the =
references to the core token binding specs, which are
   now RFCs.
o =
 Update reference to AS metadata, which is now RFC.
o  Add chairs and AD=
s to the Acknowledgements.

---------- Forwarded message ---------
From: <internet-drafts@ietf.= org>
Date: Fri, Oct 19, 2018 at 6:12 AM
Subject: [OAUTH= -WG] I-D Action: draft-ietf-oauth-token-binding-08.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 WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 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 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 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-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-19

Abstract:
=C2=A0 =C2=A0This specification enables OAuth 2.0 implementations to apply = Token
=C2=A0 =C2=A0Binding to Access Tokens, Authorization Codes, Refresh Tokens,= JWT
=C2=A0 =C2=A0Authorization Grants, and JWT Client Authentication.=C2=A0 Thi= s
=C2=A0 =C2=A0cryptographically binds these tokens to a client's Token B= inding key
=C2=A0 =C2=A0pair, possession of which is proven on the TLS connections ove= r which
=C2=A0 =C2=A0the tokens are intended to be used.=C2=A0 This use of Token Bi= nding
=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/doc/dra= ft-ietf-oauth-token-binding/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-oauth-token-binding-08


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. --000000000000465e26057893eb3b-- From nobody Fri Oct 19 05:32:02 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6F1124C04; Fri, 19 Oct 2018 05:31:55 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153995231513.32047.2574065548317837207@ietfa.amsl.com> Date: Fri, 19 Oct 2018 05:31:55 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 12:31:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-16.txt Pages : 34 Date : 2018-10-19 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-16 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 Oct 19 05:38:26 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E09127AC2 for ; Fri, 19 Oct 2018 05:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abDfoM8ELeJX for ; Fri, 19 Oct 2018 05:38:21 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E408127333 for ; Fri, 19 Oct 2018 05:38:21 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id m16-v6so22926931ioj.4 for ; Fri, 19 Oct 2018 05:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6TNcBOlKG5s3CJQmpXev8XNqyNUpZBq8g3s6QhPofc0=; b=SKnC3dJFKsiPqibdVzUbNi8OZ+fGT6CfRJPj+vPfmTYcYvzqAoqYxfULaq+hcJ/6j+ 6tlOj1SVkTVP8RfilaZr/D0fM1I3fwcnzGdobBCx8PCixs/keX/6qx9+o7dZuzA6Xc7y VYCVT8JMsZnA0WAL74rBHzZw1u3UKcdu+4Q+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:references:in-reply-to:from:date :message-id:subject:to; bh=6TNcBOlKG5s3CJQmpXev8XNqyNUpZBq8g3s6QhPofc0=; b=KehaxEjCRefR7ckQ2mKUPllhM7ZeL9G5D7qsyTo2uGD4ehTCLe3od/glRRiOmH1JXL pP3PzDlM9431KENk8MLa54wLZ+DUcs2I+2XXp6vA99EcfQIJepW5LQxKF4o/mhMJZUac 4eTJOHHibHCrTmxw42HjPoBAxfBK9QfUnM4OVMsjMzqAJIgvMkL0u6DQ7ymcnHplpUGJ juN/VBzg62Y1s+Ay4IDpvfQuQYHBH9d2UrzRhkpOSve7dSTu+WIzQ096m2NU18lRxLgT fLdCu2a11AQH6TVHMFmQC6PKzf6fCRtfKeenQHBTUcOwu3DzcC+1Unlc4XgQnaxyZJHH 2QLg== X-Gm-Message-State: AGRZ1gIkYaa4FIm3XfmrH6rJNu2EmcemSpH+cd8N3EsoH7PHPS/j2ZtA ksi8Cjt5z1lP1xEhm5LREGuagQSjQNHl2i2OIf8ESMpbyaNFC+vswSXDjx/h1Z+XpcvBMw7ALed 52aj9zUq4UBGLUrblIdI= X-Google-Smtp-Source: AJdET5dqgLX0iTfQjvyZenVs3dql526Wvodw0SAWSb1fYvRb6nPG199Jf81Eb+LM8LTsYD8p9GzMqQ365Exw6TwN7AU= X-Received: by 2002:a6b:7104:: with SMTP id q4-v6mr2391283iog.138.1539952700395; Fri, 19 Oct 2018 05:38:20 -0700 (PDT) MIME-Version: 1.0 References: <153995231513.32047.2574065548317837207@ietfa.amsl.com> In-Reply-To: <153995231513.32047.2574065548317837207@ietfa.amsl.com> From: Brian Campbell Date: Fri, 19 Oct 2018 06:37:54 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000adb0ac0578942dc7" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-exchange-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 12:38:25 -0000 --000000000000adb0ac0578942dc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not much to see here: In -16 a typo was fixed and Ben was added as an AD in the Acknowledgements. ---------- Forwarded message --------- From: Date: Fri, Oct 19, 2018 at 6:32 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-16.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-16.txt Pages : 34 Date : 2018-10-19 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-16 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000adb0ac0578942dc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not much to see here: In -16 a typo was f= ixed and Ben was added as an AD in the Acknowledgements.

---------- Forwarded message --------= -
From: <internet-drafts@ietf.org>
Date: Fri, Oct 19, 2018 at 6:3= 2 AM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-16.= 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 WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Token Exchange
=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 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-iet= f-oauth-token-exchange-16.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 34
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-19

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- b= ased
=C2=A0 =C2=A0Security Token Service (STS) by defining how to request and ob= tain
=C2=A0 =C2=A0security tokens from OAuth 2.0 authorization servers, includin= g
=C2=A0 =C2=A0security tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-oauth-token-exchange/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-oauth-token-exchange-16


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. --000000000000adb0ac0578942dc7-- From nobody Fri Oct 19 08:39:12 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C38DA130F06; Fri, 19 Oct 2018 08:39:10 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153996355076.6588.4977672222387120426@ietfa.amsl.com> Date: Fri, 19 Oct 2018 08:39:10 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 15:39:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-01.txt Pages : 13 Date : 2018-10-19 Abstract: An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the location of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 19 08:59:36 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DE913101B for ; Fri, 19 Oct 2018 08:59: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, 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 0Q6yo65hQA9Y for ; Fri, 19 Oct 2018 08:59:26 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8270D130FFB for ; Fri, 19 Oct 2018 08:59:26 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id l191-v6so4846855ita.4 for ; Fri, 19 Oct 2018 08:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yPkebPwPJL+tdbyiwIRa3TtieqRxnqMdQ3ZXDQuzEn0=; b=aB1yb5fda2n3Qv4DCD+GaiHGPJJw1DdqbYoxzdFCrag31ID/o8AlfSbzWCBMK17jLF Yxw8ypyxVmVNmWMw20olxOKfLPUGwxZWknNj9JP1I1Q0SFMb9w9hJq3vEjr2ufAzYvRX gYbi74QvzfKnBw1q9igguki4MpRUaahCqcu6g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yPkebPwPJL+tdbyiwIRa3TtieqRxnqMdQ3ZXDQuzEn0=; b=h2OzrbLN+OaYKWUx5Dpq+miTM7uD+sSkytZ9jA7Fy6qnbtekwAJPghhnDVJBibMyAY WCY/iMgxX34Hm+9QANgfYT7GNmXE0LGTSdhymTEnPYwEvJ22MwKUvhJFwpLGjyuANPiI iOQLf3rpFaNgSJf+GjmHzaXVngUq4Z8smqkPCwMe+IjYV1OtbNHzHcaM5F1zsymoZl16 ViVYdGw4Qv5nYaMBHAqVvLc7B8tzYWEhhpxIYXYs1SYmGLLW8kCBabHu5CXM1cb4JOVQ T7ccUhpPVmdFBEA6lox4FChvRVcdxo78Uajfy48HrHLkQm7yM3q/m6PaTT+p/rXchcwZ w8AA== X-Gm-Message-State: ABuFfoiJeegA3Mhkx9ACWXMgM0xbWmcYnHGD0PiBqzyokH4JbRLqFrFA bI2yqb0KTN6OIX2wenKaABP9q4t74SroaDSBN5AZ/TvD0f9A+fUSVr4dVhFhOjUIEb2xFEr2aj6 mU4RC6vQtnptkbVjfvWo= X-Google-Smtp-Source: ACcGV63msluX0Mu+oW2/CTI0TG5Kxqy14Hd61CCdyB4EfRBFp03T0LSl5vEDhgzr1CqgFLsQvmzojpDJ6jayiqgMA2s= X-Received: by 2002:a24:6882:: with SMTP id v124-v6mr3510288itb.124.1539964765303; Fri, 19 Oct 2018 08:59:25 -0700 (PDT) MIME-Version: 1.0 References: <153996355076.6588.4977672222387120426@ietfa.amsl.com> In-Reply-To: <153996355076.6588.4977672222387120426@ietfa.amsl.com> From: Brian Campbell Date: Fri, 19 Oct 2018 09:58:59 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000cd8e2a057896fcf1" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-resource-indicators-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 15:59:35 -0000 --000000000000cd8e2a057896fcf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A bit overdue but still before the impending Internet Draft submission cut-off date, -01 of Resource Indicators for OAuth 2.0 has been published. A summary of the changes, copied from the Document History, are listed below. draft-ietf-oauth-resource-indicators-01 o Significant rework of the main section of the document attempting to clarify a number of things that came up at, around and after IETF 102 and the call for adoption. o Change the "invalid_resource" error to "invalid_target" to align with draft-ietf-oauth-token-exchange, which has some overlap in functionality. o Allow the "resource" parameter value to have a query component (aligning with draft-ietf-oauth-token-exchange). o Moved the Security Considerations section to before the IANA Considerations. o Other editorial updates. o Rework the Acknowledgements section. o Use RFC 8174 boilerplate. ---------- Forwarded message --------- From: Date: Fri, Oct 19, 2018 at 9:39 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-01.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-01.txt Pages : 13 Date : 2018-10-19 Abstract: An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the location of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-= 01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-resource-indicators-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 --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000cd8e2a057896fcf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A bit overdue but s= till before the impending Internet Draft submission cut-off date, -01 of Re= source Indicators for OAuth 2.0 has been published. A summary of the change= s, copied from the Document History, are listed below.

<= /div>
draft-ietf-oauth-resource-indi=
cators-01
o  Significant rework of the main section of the document atte=
mpting
   to clarify a number of things that came up at, around and afte=
r
   IETF 102 and the call for adoption.
o  Change the "invalid_=
resource" error to "invalid_target" to align
   with draf=
t-ietf-oauth-token-exchange, which has some overlap in
   functionality.=

o  Allow the "resource" parameter value to have a query compo=
nent
   (aligning with draft-ietf-oauth-token-exchange).
o  Moved the=
 Security Considerations section to before the IANA
   Considerations.o  Other editorial updates.
o  Rework the Acknowledgements section.o  Use RFC 8174 boilerplate.


---------- Forwarded message ---------
From= : <interne= t-drafts@ietf.org>
Date: Fri, Oct 19, 2018 at 9:39 AM
S= ubject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-01.txt<= br>To: <i-d-announce@ietf.org<= /a>>
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 WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Resource Indicators 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 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-resource-indicators-01.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 := 2018-10-19

Abstract:
=C2=A0 =C2=A0An extension to the OAuth 2.0 Authorization Framework defining=
=C2=A0 =C2=A0request parameters that enable a client to explicitly signal t= o an
=C2=A0 =C2=A0authorization server about the location of the protected resou= rce(s)
=C2=A0 =C2=A0to which it is requesting access.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-oauth-resource-indicators/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft= -ietf-oauth-resource-indicators-01
https://datatracker.iet= f.org/doc/html/draft-ietf-oauth-resource-indicators-01

A diff from the previous version is available at:
https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-oauth-resource-indicators-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

<= 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. --000000000000cd8e2a057896fcf1-- From nobody Fri Oct 19 12:01:15 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0421310B4; Fri, 19 Oct 2018 11:56:34 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997539477.6592.8038096267484869807.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:34 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 103 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:43 -0000 Dear Rifaat Shekh-Yusef, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (1:30 requested) Monday, 5 November 2018, Morning Session I 0900-1100 Room Name: Meeting 2 size: 150 --------------------------------------------- oauth Session 2 (1:30 requested) Tuesday, 6 November 2018, Morning Session II 1120-1220 Room Name: Meeting 1 size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/oauth.ics Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: secevent teep suit core tls ace tokbind saag People who must be present: Eric Rescorla Hannes Tschofenig Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 19 14:14:24 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B53DB1286D9; Fri, 19 Oct 2018 14:14:15 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153998365568.6513.8592147530039175488@ietfa.amsl.com> Date: Fri, 19 Oct 2018 14:14:15 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 21:14:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-13.txt Pages : 21 Date : 2018-10-19 Abstract: This OAuth 2.0 authorization flow is designed for devices that either lack a browser to perform a user-agent based OAuth flow, or are input-constrained to the extent that requiring the user to input a lot of text (like their credentials to authenticate with the authorization server) is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources without using an on-device user-agent, provided that they have an Internet connection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-13 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 Oct 19 14:15:47 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EF4130DE5 for ; Fri, 19 Oct 2018 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=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 EanuwfzuzNot for ; Fri, 19 Oct 2018 14:15:38 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B755130DDB for ; Fri, 19 Oct 2018 14:15:34 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id l191-v6so5850875ita.4 for ; Fri, 19 Oct 2018 14:15:34 -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=ckvmqahYJq8unTdh3HePvJr8QiuEOuvg6JqeSFYamvc=; b=Pc5zY7NrRtzH8QVkXwayNN19G7Gzm3996X1+8fr4ycReExQB2J1HC5EO2zpYkND/XQ npRAkcZ2Dwj7jdXzifTd6wz91Zv7OlDhQYKNgPtXSbcudAGVkUS3xOmz9hSreOulrf4x WtxgfGObypnQsxQblaSW4f/d8Qy+9w+FAOJHmwGh7BX+v1hKbdY88y1tGP67NhYWwJSk l/tC6LwUwLwNO5vFaujcfGpAg/2qbkKRJa7uvLkNO0+eSQkdFHd0PDnoO9ZiRVVkfr1B J83MpCM+jTrQjIU6/GqF9+bmhFTOgbcoo2wE2274P19nIFH47v67XZ/d/78oQQFedulI 74hA== 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=ckvmqahYJq8unTdh3HePvJr8QiuEOuvg6JqeSFYamvc=; b=UzmIHpVP4sKOURukAvn4pE7WPaZgy7nw60mo6ofxc1w8hQXwbUyMx0VWifqajr8+6A ZB8nuIYQt5tZZUkfNs08XvAa8y22G4bH8THgUn6efnpUgYkI4Y5jkmHcmdJzwxz5uUKT IfUjAUA6DwCVuwscmJcytAbI7be2ubY2E7bgYRdS50HzICAoPEEJmj53erOWnbnKVJTK vbCEyi96EzCDFm0pLoZxP17DvzrP9PACO+dd5fqOENFsCfJb3XdFq7RCJyMx5j2XK6eb M80wkCcYqN3xzwXtb9vfCYdADah9GQ/lHr+sTf7l9v/wdGD8rvNgsn3lWlLx9cozJFWe eWzQ== X-Gm-Message-State: ABuFfohw2/eQSEgSCNZv7fb4gWJMVA27TU7NVzLAQs8pYNGpQ01UgoFA LU9lQ4HeTMDvdUO6P4nX4OLU9mi3pZNzDfNkfAofSw== X-Google-Smtp-Source: ACcGV63maVhrgl4kBja4gyQvvbKOsOBHaLMRSnVRc4HN4x+aWFpMyUxFgrSpPpOIxy7i8dQAMUTOUZ4U/bJMiSxIzMY= X-Received: by 2002:a24:de83:: with SMTP id d125-v6mr4104969itg.137.1539983733414; Fri, 19 Oct 2018 14:15:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:e30a:0:0:0:0:0 with HTTP; Fri, 19 Oct 2018 14:15:12 -0700 (PDT) In-Reply-To: <153317059661.22107.3645320244647621058.idtracker@ietfa.amsl.com> References: <153317059661.22107.3645320244647621058.idtracker@ietfa.amsl.com> From: William Denniss Date: Fri, 19 Oct 2018 14:15:12 -0700 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000644a8b05789b676b" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-device-flow-12: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 21:15:40 -0000 --000000000000644a8b05789b676b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adam, Thank you for your feedback and pointers, version 13 should fully address your feedback. Comments inline: On Wed, Aug 1, 2018 at 5:43 PM, Adam Roach wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks to the authors for addressing my comments and half of my DISCUSS. > This final issue appears to remain unaddressed: > > =C2=A73.1: > > > The client initiates the flow by requesting a set of verification > > codes from the authorization server by making an HTTP "POST" request > > to the device authorization endpoint. The client constructs the > > request with the following parameters, encoded with the "application/ > > x-www-form-urlencoded" content type: > > This document needs a normative citation for this media type. > > My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as > this > appears to be the most recent stable description of how to encode this > media > type. I'd love to hear rationale behind other citations being more > appropriate, > since I'm not entirely happy with the one I suggest above (given that it'= s > been > superseded by HTML 5.2); but every other plausible citation I can find is > even > less palatable (with HTML 5.2 itself having the drawback of not actually > defining how to encode the media type, instead pointing to an unstable, > unversioned document). > Thank you for the advice. I've struggled with this one myself. HTML 5.2 like you say links to an unstable and unversioned document (albeit one that is readable and pleasant for implementors). I wish they had a proper stable reference, it seems odd to normatively reference something that isn't stable to me, but what can we do? I went with the exact reference you suggested, it's in version 13. Best, William --000000000000644a8b05789b676b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adam,

Thank you for your feedback and pointers, ve= rsion 13 should fully address your feedback.=C2=A0 Comments inline:

On Wed, Aug 1, 2018 a= t 5:43 PM, Adam Roach <adam@nostrum.com> wrote:

-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thanks to the authors for addressing my comments and half of my DISCUSS. This final issue appears to remain unaddressed:

=C2=A73.1:

>=C2=A0 The client initiates the flow by requesting a set of verificatio= n
>=C2=A0 codes from the authorization server by making an HTTP "POST= " request
>=C2=A0 to the device authorization endpoint.=C2=A0 The client construct= s the
>=C2=A0 request with the following parameters, encoded with the "ap= plication/
>=C2=A0 x-www-form-urlencoded" content type:

This document needs a normative citation for this media type.

My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as thi= s
appears to be the most recent stable description of how to encode this medi= a
type. I'd love to hear rationale behind other citations being more appr= opriate,
since I'm not entirely happy with the one I suggest above (given that i= t's been
superseded by HTML 5.2); but every other plausible citation I can find is e= ven
less palatable (with HTML 5.2 itself having the drawback of not actually defining how to encode the media type, instead pointing to an unstable,
unversioned document).

Thank you for th= e advice. I've struggled with this one myself. HTML 5.2 like you say li= nks to an unstable and unversioned document (albeit one that is readable an= d pleasant for implementors). I wish they had a proper stable reference, it= seems odd to normatively reference something that isn't stable to me, = but what can we do?

I went with the exact referenc= e you suggested, it's in version 13.

Best,
William

--000000000000644a8b05789b676b-- From nobody Fri Oct 19 14:27:53 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34B11310C3 for ; Fri, 19 Oct 2018 14:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBe5-JT09FfM for ; Fri, 19 Oct 2018 14:27:46 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CD91310B7 for ; Fri, 19 Oct 2018 14:27:39 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id c23-v6so5876370itd.5 for ; Fri, 19 Oct 2018 14:27:39 -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=QFkDDTtPLk8EkQtwn3rl82w06B83aEG4g9TdrUk1mM8=; b=kA2jMCYrq4DL16weWxpjVATHJJh3xGzeqT75ptvhVEqGbwJGiHalfXtAJHZYPeK/rx RZoHcl/0PGNmn2vdSIlUYXGxKXIcKzYuASw1MNwsUaK5YNOjp0q2WU7z2Sim7KKM4BiF lEDzF7X0GvCBQF3IPKHOT3ZAvuq7kQJ+WNQrzUIhSpJWQ58jWlcIaHxl5p4ldzx90n3y BpJR+0c3t3iK8CEL92hzkg2hAZCai1o5x7nhtLQ/1jBeW8MZ81GEROGAvIpbfjkf8zHg aSIpKL6OwQpGS83OL9ROQoQXIGiGy5dgH3q73qZITxnNmwWXsvpNtEHC+kGGZIo1pWY1 5Dcg== 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=QFkDDTtPLk8EkQtwn3rl82w06B83aEG4g9TdrUk1mM8=; b=LeJwwv9y80nSCctBxHtYIHVx7zXEklomwMDehhK/uwXRC2MZEeQObdk2O8Te6CN1pT Eu2OT7Ksx8gr/2llfXEsqANoxPAiH2+D48ICAwzRiR625ChX8IQB1T2dE0oBzwJhPCEG 43jSD8kB8vVAtCF90Wmd1qfC5iDDb0A5waEUHG6zlKWKErV7MqG0P5WzKvVFAJRt54fj IENb+vYdB1nuzwZUt//SJau4GMpcp6SLdT9gs3ii9Flt/YeSJZqBTaFaxKIoCSJKVLyC O3E3756o2PA3yIPn2TU8QvUt7dlBC2YX2LgtP9D+tV3I3J6z5NVqTMyUoDXYNv0UvpUs VKtQ== X-Gm-Message-State: ABuFfoj++DkgJza+UD4d0wi2m8Vec4k7yRI6t8UgG+BgUwbTgnSIin6V wTzjQR04pVWPM7YB3glwZxbf7/i98SvksvLS0GNr5fF7KNw= X-Google-Smtp-Source: ACcGV613+ZjalGwaupKSiRrp8/Ubxa78d0qYspbkGgsdpLvbKFV3ZwsENAu4XxYviBuGuymPvWRf6HqFrigVN4ldryE= X-Received: by 2002:a24:ef05:: with SMTP id i5-v6mr4676781ith.125.1539984458116; Fri, 19 Oct 2018 14:27:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:e30a:0:0:0:0:0 with HTTP; Fri, 19 Oct 2018 14:27:17 -0700 (PDT) In-Reply-To: <20180803002107.GE68224@kduck.kaduk.org> References: <153243911759.22454.13623930642678414831.idtracker@ietfa.amsl.com> <20180803002107.GE68224@kduck.kaduk.org> From: William Denniss Date: Fri, 19 Oct 2018 14:27:17 -0700 Message-ID: To: Benjamin Kaduk Cc: William Denniss , Rifaat Shekh-Yusef , oauth , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="000000000000967e2205789b92a4" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 21:27:51 -0000 --000000000000967e2205789b92a4 Content-Type: text/plain; charset="UTF-8" Hi Benjamin, Thank you for your detailed review, and suggestions. Version 13 was just posted, and incorporates your suggestions and feedback. Replies inline: On Thu, Aug 2, 2018 at 5:21 PM, Benjamin Kaduk wrote: > On Wed, Aug 01, 2018 at 05:16:52PM -0700, William Denniss wrote: > > Benjamin, > > > > Thank you for the feedback. We just posted version 12 which addresses > many > > of your feedback points. Replies inline. > > > > On Tue, Jul 24, 2018 at 6:31 AM, Benjamin Kaduk wrote: > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > Let me preface this by noting that I'm not sure that all of these > points > > > are actionable; I would, however, like to discuss them. > > > > > > I'm really unhappy to not see any hard numbers on the entropy needed > > > in a user code to provide a reasonable security margin with given > > > parameters, and how it compares to the guessability bounds considered > best > > > practices in general (across protocols). For example, we think 128-bit > > > symmetric keys are okay because an attacker has to put in 2**96 work to > > > have a 2**-32 chance of guessing correctly via brute force; the rate > > > limiting and finite lifetime on the user code places an artificial > limit on > > > the amount of work an attacker can "do", so if one uses a 8-character > > > base-20 user code (with roughly 34.5 bits of entropy), the > rate-limiting > > > interval and validity period would need to only allow 5 attempts in > order > > > to get the same 2**-32 probability of success by random guessing. > > > Section 5.1 would be a great place for such text, near the preexisting: > > > The user code SHOULD have enough entropy that when combined with > rate > > > limiting and other mitigations makes a brute-force attack > infeasible. > > > > > > > > Thank you for the comment, the authors are still considering the right > way > > to address this feedback. > > > > > > > > > We talk about "the authorization server", but any given *user* may > have a > > > relationship with multiple such ASes. Can the Introduction make it > more > > > clear that the AS is associated with the device/client, and as such the > > > it may not be the user's most-trusted AS? > > > > > > > Sometimes the device is really an app on the device. E.g. a Roku TV > device > > (a "tv stick") that has several apps. Hulu, where the AS is hulu, and > > YouTube, where the AS is YouTube (these are both "first party" use-cases > > where the app and the AS are owned by the same entity). The user may also > > have a Canon printer, which has a device flow to Google, to authorize it > to > > print documents (a "third-party" use-case). > > > > I'm not sure exactly what we should say in the introduction to address > you > > feedback here. > > The document text is currently referring to a single AS (the definite > article "the" in "the authorization server" as if everyone knows which one > to use as a prerequisite of using this flow. That is presumably true for > the devices in question, but it's not necessarily true for the reader of > the spec. So, I'd propose to say something like "connect to the device's > authorization server to approve the access request" or "connect to the > authorization server that the device trusts to mediate authorization > decisions". (Gosh, it's hard to write the second one without using > "grant"!) > I added a section in the introduction to clarify the relationship of the device to the AS: The device typically chooses the set of authorization servers to support (i.e., its own authorization server, or those by providers it has relationships with). It is not uncommon for the device application to support only a single authorization server, such as with a TV application for a specific media provider that supports only that media provider's authorization server. The user may not have an established relationship yet with that authorization provider, though one can potentially be set up during the authorization flow. Does that improve the understanding of this concept? I can add the text your propose directly too. > > > It also seems like a large latent risk with this flow is when the > > > verification_uri_complete response is used along with an AS that > assumes an > > > authenticated user making such a verification request has approved the > > > authorization (i.e., without an explicit user interaction to confirm), > when > > > that AS uses cookies or other persistent state to keep the user > > > authenticated across multiple requests. I could not find any > MUST-level > > > requirement for user interaction to confirm the device being authorized > > > (even in Section 3.3, which covers the regular verificat_uri > workflow!); > > > please let me know if I missed something. I would like to see some > > > explicit text that (matching the flow described in Section 3.1 that > > > requires the user to input the code) explicit user approval of the > > > authorization is required. (I do note that Section 5.3 has text about > > > "SHOULD display information about the device.) > > > > > > > When verification_uri is used, the user has 2 steps (at least): 1. enter > > code, 2. consent to the request. verification_uri_complete skips the > first > > step, but the presumption is that they would still consent to the request > > in the second step. We can make this more clear if it isn't currently. > > Please do; it's an important property of the flow. > The section on verification_uri_complete was updated to reflect this feedback. > > > I'm also unhappy about the text in Section 1 that merely requires of the > > > device the ability to "make outbound HTTPS requests", which leaves > room for > > > an awful lot of sins in certificate validation (and, potentially, > > > ciphersuite selection). Can we get a MUST-level requirement for > > > authenticating the server and a cite to RFC 7525? > > > > > > > Reference to 7525 has been added. > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Please use the RFC 8174 boilerplate instead of the RFC 2119 one. > > > > > > > Done, thanks! > > > > > > > > > > Section 3.2 > > > > > > The example expires in 30 minutes? That seems longer than needed; > wouldn't > > > 5 minutes do? > > > > > > > Incidentally, 30 minutes is the value Google returns on the requests, > which > > was where this example came from. > > > > In general I think it's good to have a reasonable window of time as the > > user does need to find another device, open the browser, login to the AS > > (possibly recover their passowrd), etc. There are some edge-cases in the > > device flow too where if you enter the code right when it expires, you'll > > get an error and need to start-over, and the longer the window of > > opportunity the less this occurs. > > Sure. I'm mostly just thinking in terms of the rate-limiting/entropy issue > that's part of my DISCUSS -- cutting this window down lets a shorter code > be used for a given security margin, but of course only as a linear factor. > We've added a longer discussion on entropy in version 13 (using part of the text you wrote, thank you for that!) There are a lot of factors that go into this decision by the AS when choosing the timeout, rate limiting, and the entropy. Another example mitigation is requiring users to be logged in, thus any brute-forcing behavior could be monitored at an account level, providing an additional account-based rate limit. We've left the sample at 30 minutes for now, please let us know what you think. > > > > > > > > Section 3.3 > > > > > > I agree with directorate reviewer that the MUST NOT requirement for > > > displaying the device_code should justify that requirement by > discussing > > > the consequences of exposure. > > > > > > > > > Text has been updated, now reads: > > > > It is NOT RECOMMENDED for authorization servers to include the user > > code in the verification URI ("verification_uri"), as this increases > > the length and complexity of the URI that the user must type. The > > next section documents user interaction with > > "verification_uri_complete", which is designed to carry this > > information. > > Thanks! > > -Benjamin > > > > > > > > > > > > > Section 3.5 > > > > > > authorization_pending > > > The authorization request is still pending as the end-user hasn't > > > yet completed the user interaction steps (Section 3.3). The > > > client should repeat the Access Token Request to the token > > > endpoint. > > > > > > I feel like we want to mention the 'interval' here or some other > discussion > > > of an inter-request delay. > > > > > > > This text has been reorganized, with some duplication removed and I think > > it reads better now. > > > > > > > Also, please clarify "reasonable default polling interval", per > multiple > > > directorate reviews. > > > > > > > Done, we set it to 5s. > > > > > > > > > > Section 5.2 > > > > > > Please clarify the entities involved in "the backchannel flow" that > can be > > > MITM'd. > > > > > > > The authors are still considering text to address this feedback. > > > > > > > > > > Section 5.6 > > > > > > The "short-range" part of a "short-range wireless signal" partially > depends > > > on how big the receiver's antenna is. So perhaps we should be careful > > > about indicating that this has more security value than it does. > > > > > > > Dropped the reference to "short-range wireless signal". > > > > > > > > > > Section 6.1 > > > > > > I'm not sure I understand the usage of "case-insensitive", here -- how > > > would the user have an expectation of case-insensitivity? Perhaps it > is > > > better to just say "majuscule" or "upper case" or whatever. > > > > > > > > This section was reworded to hopefully address your feedback. > > > > Best, > > William > Best, William --000000000000967e2205789b92a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,

Thank you for your detailed review, and suggestio= ns. Version 13 was just posted, and incorporates your suggestions and feedb= ack.

Replies inline:

On Thu, Aug 2, 2018= at 5:21 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
On Wed, Aug 01, 2018 at 0= 5:16:52PM -0700, William Denniss wrote:
> Benjamin,
>
> Thank you for the feedback. We just posted version 12 which addresses = many
> of your feedback points. Replies inline.
>
> On Tue, Jul 24, 2018 at 6:31 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> >
> > ------------------------------------------------------------= ----------
> > DISCUSS:
> > ------------------------------------------------------------= ----------
> >
> > Let me preface this by noting that I'm not sure that all of t= hese points
> > are actionable; I would, however, like to discuss them.
> >
> > I'm really unhappy to not see any hard numbers on the entropy= needed
> > in a user code to provide a reasonable security margin with given=
> > parameters, and how it compares to the guessability bounds consid= ered best
> > practices in general (across protocols).=C2=A0 For example, we th= ink 128-bit
> > symmetric keys are okay because an attacker has to put in 2**96 w= ork to
> > have a 2**-32 chance of guessing correctly via brute force; the r= ate
> > limiting and finite lifetime on the user code places an artificia= l limit on
> > the amount of work an attacker can "do", so if one uses= a 8-character
> > base-20 user code (with roughly 34.5 bits of entropy), the rate-l= imiting
> > interval and validity period would need to only allow 5 attempts = in order
> > to get the same 2**-32 probability of success by random guessing.=
> > Section 5.1 would be a great place for such text, near the preexi= sting:
> >=C2=A0 =C2=A0 The user code SHOULD have enough entropy that when c= ombined with rate
> >=C2=A0 =C2=A0 limiting and other mitigations makes a brute-force a= ttack infeasible.
> >
> >
> Thank you for the comment, the authors are still considering the right= way
> to address this feedback.
>
>
>
> > We talk about "the authorization server", but any given= *user* may have a
> > relationship with multiple such ASes.=C2=A0 Can the Introduction = make it more
> > clear that the AS is associated with the device/client, and as su= ch the
> > it may not be the user's most-trusted AS?
> >
>
> Sometimes the device is really an app on the device. E.g. a Roku TV de= vice
> (a "tv stick") that has several apps. Hulu, where the AS is = hulu, and
> YouTube, where the AS is YouTube (these are both "first party&quo= t; use-cases
> where the app and the AS are owned by the same entity). The user may a= lso
> have a Canon printer, which has a device flow to Google, to authorize = it to
> print documents (a "third-party" use-case).
>
> I'm not sure exactly what we should say in the introduction to add= ress you
> feedback here.

The document text is currently referring to a single AS (the de= finite
article "the" in "the authorization server" as if every= one knows which one
to use as a prerequisite of using this flow.=C2=A0 That is presumably true = for
the devices in question, but it's not necessarily true for the reader o= f
the spec.=C2=A0 So, I'd propose to say something like "connect to = the device's
authorization server to approve the access request" or "connect t= o the
authorization server that the device trusts to mediate authorization
decisions".=C2=A0 (Gosh, it's hard to write the second one without= using
"grant"!)

I added a section i= n the introduction to clarify the relationship of the device to the AS:

   The device t=
ypically chooses the set of authorization servers to
   support (i.e., its own authorization server, or those by providers it
   has relationships with).  It is not uncommon for the device
   application to support only a single authorization server, such as
   with a TV application for a specific media provider that supports
   only that media provider's authorization server.  The user may not
   have an established relationship yet with that authorization
   provider, though =
one can potentially be set up during the
   authorization flow.

Does that impr= ove the understanding of this concept? I can add the text your propose dire= ctly too.=C2=A0
=C2=A0

> It also seems like a large latent risk with this flow is when the
> > verification_uri_complete response is used along with an AS that = assumes an
> > authenticated user making such a verification request has approve= d the
> > authorization (i.e., without an explicit user interaction to conf= irm), when
> > that AS uses cookies or other persistent state to keep the user > > authenticated across multiple requests.=C2=A0 I could not find an= y MUST-level
> > requirement for user interaction to confirm the device being auth= orized
> > (even in Section 3.3, which covers the regular verificat_uri work= flow!);
> > please let me know if I missed something.=C2=A0 I would like to s= ee some
> > explicit text that (matching the flow described in Section 3.1 th= at
> > requires the user to input the code) explicit user approval of th= e
> > authorization is required.=C2=A0 (I do note that Section 5.3 has = text about
> > "SHOULD display information about the device.)
> >
>
> When verification_uri is used, the user has 2 steps (at least): 1. ent= er
> code, 2. consent to the request. verification_uri_complete skips the f= irst
> step, but the presumption is that they would still consent to the requ= est
> in the second step. We can make this more clear if it isn't curren= tly.

Please do; it's an important property of the flow.

The section on verification_uri_complete was updated= to reflect this feedback.
=C2=A0

> I'm also unhappy about the text in Section 1 that merely requires = of the
> > device the ability to "make outbound HTTPS requests", w= hich leaves room for
> > an awful lot of sins in certificate validation (and, potentially,=
> > ciphersuite selection).=C2=A0 Can we get a MUST-level requirement= for
> > authenticating the server and a cite to RFC 7525?
> >
>
> Reference to 7525 has been added.
>
>
> > ------------------------------------------------------------= ----------
> > COMMENT:
> > ------------------------------------------------------------= ----------
> >
> > Please use the RFC 8174 boilerplate instead of the RFC 2119 one.<= br> > >
>
> Done, thanks!
>
>
> >
> > Section 3.2
> >
> > The example expires in 30 minutes?=C2=A0 That seems longer than n= eeded; wouldn't
> > 5 minutes do?
> >
>
> Incidentally, 30 minutes is the value Google returns on the requests, = which
> was where this example came from.
>
> In general I think it's good to have a reasonable window of time a= s the
> user does need to find another device, open the browser, login to the = AS
> (possibly recover their passowrd), etc. There are some edge-cases in t= he
> device flow too where if you enter the code right when it expires, you= 'll
> get an error and need to start-over, and the longer the window of
> opportunity the less this occurs.

Sure.=C2=A0 I'm mostly just thinking in terms of the rate-limiti= ng/entropy issue
that's part of my DISCUSS -- cutting this window down lets a shorter co= de
be used for a given security margin, but of course only as a linear factor.=

We've added a longer = discussion on entropy in version 13 (using part of the text you wrote, than= k you for that!)

There are a lot of factors that g= o into this decision by the AS when choosing the timeout, rate limiting, an= d the entropy. Another example mitigation is requiring users to be logged i= n, thus any brute-forcing behavior could be monitored at an account level, = providing an additional account-based rate limit. We've left the sample= at 30 minutes for now, please let us know what you think.
=C2=A0=
>
> >
> > Section 3.3
> >
> > I agree with directorate reviewer that the MUST NOT requirement f= or
> > displaying the device_code should justify that requirement by dis= cussing
> > the consequences of exposure.
> >
>
>
> Text has been updated, now reads:
>
>=C2=A0 =C2=A0 It is NOT RECOMMENDED for authorization servers to includ= e the user
>=C2=A0 =C2=A0 code in the verification URI ("verification_uri"= ;), as this increases
>=C2=A0 =C2=A0 the length and complexity of the URI that the user must t= ype.=C2=A0 The
>=C2=A0 =C2=A0 next section documents user interaction with
>=C2=A0 =C2=A0 "verification_uri_complete", which is designed = to carry this
>=C2=A0 =C2=A0 information.

Thanks!

-Benjamin

>
>
>
> >
> > Section 3.5
> >
> >=C2=A0 =C2=A0 authorization_pending
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0The authorization request is still pend= ing as the end-user hasn't
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0yet completed the user interaction step= s (Section 3.3).=C2=A0 The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0client should repeat the Access Token R= equest to the token
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint.
> >
> > I feel like we want to mention the 'interval' here or som= e other discussion
> > of an inter-request delay.
> >
>
> This text has been reorganized, with some duplication removed and I th= ink
> it reads better now.
>
>
> > Also, please clarify "reasonable default polling interval&qu= ot;, per multiple
> > directorate reviews.
> >
>
> Done, we set it to 5s.
>
>
> >
> > Section 5.2
> >
> > Please clarify the entities involved in "the backchannel flo= w" that can be
> > MITM'd.
> >
>
> The authors are still considering text to address this feedback.
>
>
> >
> > Section 5.6
> >
> > The "short-range" part of a "short-range wireless = signal" partially depends
> > on how big the receiver's antenna is.=C2=A0 So perhaps we sho= uld be careful
> > about indicating that this has more security value than it does.<= br> > >
>
> Dropped the reference to "short-range wireless signal".
>
>
> >
> > Section 6.1
> >
> > I'm not sure I understand the usage of "case-insensitive= ", here -- how
> > would the user have an expectation of case-insensitivity?=C2=A0 P= erhaps it is
> > better to just say "majuscule" or "upper case"= ; or whatever.
> >
> >
> This section was reworded to hopefully address your feedback.
>
> Best,
> William

Best,
William
=C2=A0

--000000000000967e2205789b92a4-- From nobody Fri Oct 19 14:32:37 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC57913106B; Fri, 19 Oct 2018 14:32:17 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153998473756.6525.1946841573679679258@ietfa.amsl.com> Date: Fri, 19 Oct 2018 14:32:17 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-distributed-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 21:32:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Distributed OAuth Authors : Dick Hardt Brian Campbell Nat Sakimura Filename : draft-ietf-oauth-distributed-00.txt Pages : 9 Date : 2018-10-19 Abstract: The Distributed OAuth profile enables an OAuth client to discover what authorization server or servers may be used to obtain access tokens for a given resource, and what parameter values to provide in the access token request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-distributed/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-distributed-00 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-distributed-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 19 15:35:05 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F82130E8F; Fri, 19 Oct 2018 15:35:04 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153998850411.20283.6996939312775123820@ietfa.amsl.com> Date: Fri, 19 Oct 2018 15:35:04 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 22:35:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Reciprocal OAuth Author : Dick Hardt Filename : draft-ietf-oauth-reciprocal-01.txt Pages : 5 Date : 2018-10-19 Abstract: There are times when a user has a pair of protected resources that would like to request access to each other. While OAuth flows typically enable the user to grant a client access to a protected resource, granting the inverse access requires an additional flow. Reciprocal OAuth enables a more seamless experience for the user to grant access to a pair of protected resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-reciprocal-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 19 16:54:43 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4770113113C; Fri, 19 Oct 2018 16:54:25 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153999326524.20283.13820902993417475344@ietfa.amsl.com> Date: Fri, 19 Oct 2018 16:54:25 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-distributed-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 23:54:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Distributed OAuth Authors : Dick Hardt Brian Campbell Nat Sakimura Filename : draft-ietf-oauth-distributed-01.txt Pages : 9 Date : 2018-10-19 Abstract: The Distributed OAuth profile enables an OAuth client to discover what authorization server or servers may be used to obtain access tokens for a given resource, and what parameter values to provide in the access token request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-distributed/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-distributed-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-distributed-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 19 17:00:21 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0248D130DE6; Fri, 19 Oct 2018 17:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 9oTVRH93dPaf; Fri, 19 Oct 2018 17:00:10 -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 945811310AF; Fri, 19 Oct 2018 17:00:10 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9K000ld034964 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Oct 2018 19:00:02 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: William Denniss Cc: The IESG , draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, oauth References: <153317059661.22107.3645320244647621058.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <4a4e12f8-7392-fdef-29be-482ddddb46a3@nostrum.com> Date: Fri, 19 Oct 2018 18:59:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D4CE21B96D9325724FCA68D8" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-device-flow-12: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 00:00:13 -0000 This is a multi-part message in MIME format. --------------D4CE21B96D9325724FCA68D8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks. I have entered a ballot of "no objection." /a On 10/19/18 4:15 PM, William Denniss wrote: > Adam, > > Thank you for your feedback and pointers, version 13 should fully > address your feedback.  Comments inline: > > On Wed, Aug 1, 2018 at 5:43 PM, Adam Roach > wrote: > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks to the authors for addressing my comments and half of my > DISCUSS. > This final issue appears to remain unaddressed: > > §3.1: > > >  The client initiates the flow by requesting a set of verification > >  codes from the authorization server by making an HTTP "POST" > request > >  to the device authorization endpoint.  The client constructs the > >  request with the following parameters, encoded with the > "application/ > >  x-www-form-urlencoded" content type: > > This document needs a normative citation for this media type. > > My suggestion would be to cite REC-html5-20141028 section > 4.10.22.6, as this > appears to be the most recent stable description of how to encode > this media > type. I'd love to hear rationale behind other citations being more > appropriate, > since I'm not entirely happy with the one I suggest above (given > that it's been > superseded by HTML 5.2); but every other plausible citation I can > find is even > less palatable (with HTML 5.2 itself having the drawback of not > actually > defining how to encode the media type, instead pointing to an > unstable, > unversioned document). > > > Thank you for the advice. I've struggled with this one myself. HTML > 5.2 like you say links to an unstable and unversioned document (albeit > one that is readable and pleasant for implementors). I wish they had a > proper stable reference, it seems odd to normatively reference > something that isn't stable to me, but what can we do? > > I went with the exact reference you suggested, it's in version 13. > > Best, > William > --------------D4CE21B96D9325724FCA68D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks. I have entered a ballot of "no objection."

/a

On 10/19/18 4:15 PM, William Denniss wrote:
Adam,

Thank you for your feedback and pointers, version 13 should fully address your feedback.  Comments inline:

On Wed, Aug 1, 2018 at 5:43 PM, Adam Roach <adam@nostrum.com> wrote:

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors for addressing my comments and half of my DISCUSS.
This final issue appears to remain unaddressed:

§3.1:

>  The client initiates the flow by requesting a set of verification
>  codes from the authorization server by making an HTTP "POST" request
>  to the device authorization endpoint.  The client constructs the
>  request with the following parameters, encoded with the "application/
>  x-www-form-urlencoded" content type:

This document needs a normative citation for this media type.

My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as this
appears to be the most recent stable description of how to encode this media
type. I'd love to hear rationale behind other citations being more appropriate,
since I'm not entirely happy with the one I suggest above (given that it's been
superseded by HTML 5.2); but every other plausible citation I can find is even
less palatable (with HTML 5.2 itself having the drawback of not actually
defining how to encode the media type, instead pointing to an unstable,
unversioned document).

Thank you for the advice. I've struggled with this one myself. HTML 5.2 like you say links to an unstable and unversioned document (albeit one that is readable and pleasant for implementors). I wish they had a proper stable reference, it seems odd to normatively reference something that isn't stable to me, but what can we do?

I went with the exact reference you suggested, it's in version 13.

Best,
William


--------------D4CE21B96D9325724FCA68D8-- From nobody Sun Oct 21 07:17:35 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 357C1124C04; Sun, 21 Oct 2018 07:17:28 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154013144816.10665.18251365139016891307@ietfa.amsl.com> Date: Sun, 21 Oct 2018 07:17:28 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2018 14:17:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-17.txt Pages : 27 Date : 2018-10-21 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 21 07:21:11 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2F7126CB6 for ; Sun, 21 Oct 2018 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOS-KZ7D55iE for ; Sun, 21 Oct 2018 07:21:07 -0700 (PDT) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C888124C04 for ; Sun, 21 Oct 2018 07:21:06 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs03.index.or.jp (Postfix) with ESMTP id C727117EA43 for ; Sun, 21 Oct 2018 23:21:05 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 553AF4E0046 for ; Sun, 21 Oct 2018 23:21:05 +0900 (JST) Received: from nriea03.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id w9LEL5jI026991 for ; Sun, 21 Oct 2018 23:21:05 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp with ESMTP id w9LEL4cu026990 for ; Sun, 21 Oct 2018 23:21:05 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w9LEL6HK008825; Sun, 21 Oct 2018 23:21:06 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w9LEL6sV008824; Sun, 21 Oct 2018 23:21:06 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w9LEL6b7008821 for ; Sun, 21 Oct 2018 23:21:06 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM07PA.cu.nri.co.jp (172.159.253.49) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 21 Oct 2018 23:21:04 +0900 Received: from JPN01-OS2-obe.outbound.protection.outlook.com (23.103.139.150) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 21 Oct 2018 23:21:03 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EbWoCQNzeT2ZpfZiDsAwi/FJmXVdZcxzIddgV9GNGxI=; b=LcUcKElylXvB+bNfX4T+fAH87DTIRH+QABfIj5yT3uKw1qyh9aYZ1+nF02PdGd4GkEzKLPEi56Q4ShCrxx/Dquc9lh8Hgzf3hsJK7C2RXjov1R5kjaA7q/A/EvdYAgC2f4hnmojsg0qCWR76nVfMzDXk0RNIFp+sK85pPIFfvBA= Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB2326.jpnprd01.prod.outlook.com (52.134.252.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Sun, 21 Oct 2018 14:21:03 +0000 Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%3]) with mapi id 15.20.1250.028; Sun, 21 Oct 2018 14:21:03 +0000 From: n-sakimura To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-ietf-oauth-jwsreq-17.txt Thread-Index: AQHUaUjOzrpKfTh0102tz7uURKq6EaUpv0/Q Date: Sun, 21 Oct 2018 14:21:03 +0000 Message-ID: References: <154013144839.10665.17922444927183639100.idtracker@ietfa.amsl.com> In-Reply-To: <154013144839.10665.17922444927183639100.idtracker@ietfa.amsl.com> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [40.67.185.125] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; OSBPR01MB2326; 6:5eBeJtEAZNgijH6CUi7bevThZEV6pcvlm1wVLh1FqO0t5pHscgDKLcoOcN/XndyXVFK4QrNryfSB32lsibyPMcMepnJr6c5BC6mIAa5Fu757m+zKYvRicFjC5JH0in01vGm0+W8UCeDSDlku0htAOkwKBUUFA4ivxjDKfmUVV9qPYZREsxjpPMR9ATJzCuNrB69jRz6xyDwSKxFfZU/OmeNMAotB31/ThzT9Ur1TXkLGWlr/yq8l28CbRGU2mgGL5q957PwMwPN1icg5/ifdhadnVzeWN5MLgxMUsU5YowQqMJCdZb/9c3N6H1CITpDOQUXNqfYX1LeHn5bxk9B4w4HX4cuSVdg8CZ2oGmBO+uCOsqcAwMfw3E0PlkLUeYdNS9dCVgMSq2a7RzjLWBzqbXp1+tk0zYe5qvR+hgPAXvlTK8tN9UC+V9LkUBpAVYeZrd1iBX/AO367ZlJpo5lTDw==; 5:kjgkB5CLVOhRHxYcJvQRzxxpd1+r4WWtZQED1NTyTxWo9U2PBMIxmGCuADoErURmNxv+xmLp9RuSkenXmqNbs55eRmk+fhHjtvqNmwZdRKvm8t95E+hqQke52ygce3xUkpcR8YDS7cLhtOotN0imK4v1fC4V78J8AXZxGqTv7uc=; 7:3XMvVwtyFBB9GbhxIFxEv1QtCQ5liUF2Lf2wOgCZCmoMreOPN5NkmAvQOPENLxIrcEmGxz+59fHqjiBiVl837IDRQ3WGmg2GLTG6HjsvwcF31pxL66i0vTJFR0jmxruYreVpm91etcXrEDMSBIWgqE4mipcV0PUitf8glzOyUJQ/z32l9lasjJ2t4bnffMf15QN04JYA66bx16cTfz4oxQasEUsaG7OLm3xwC3JeWc9FAjzBqxjyboFUBm70pIIR x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0bfc0d05-5df4-4036-6b71-08d637606eab x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB2326; x-ms-traffictypediagnostic: OSBPR01MB2326: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(111885846020525); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(148016)(149066)(150057)(6041310)(2016111802025)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB2326; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB2326; x-forefront-prvs: 083289FD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(346002)(376002)(39830400003)(189003)(199004)(55016002)(66066001)(68736007)(6436002)(8676002)(1730700003)(5660300001)(81156014)(81166006)(6916009)(8936002)(5640700003)(5250100002)(33656002)(97736004)(316002)(71190400001)(71200400001)(7736002)(74482002)(74316002)(102836004)(3846002)(6506007)(6116002)(2501003)(2906002)(6346003)(2900100001)(26005)(4001150100001)(99286004)(76176011)(2351001)(7696005)(15650500001)(186003)(229853002)(14444005)(11346002)(446003)(86362001)(476003)(25786009)(486006)(256004)(14454004)(966005)(106356001)(6306002)(9686003)(2473003)(54896002)(105586002)(53936002)(508600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB2326; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-microsoft-antispam-message-info: aq7FyKeRyNIbN8PTQH5yE9BDwhBFPBLaKkPA3rtjSsNZqSoH6lh3SrSuRZHiTZJC1HWYNmORfZr+OWR3d0m9QuOTjlztYhklq/Sq22yN9KhdLcXPnd3uRMgmRglme4l6gdSUhwLypnRXi5fVPjUFBg2Ta4zhavQWVm+itWAwel5tTOGturVr/6P5ax2nsgBRFI8UKt6QQFONNnCuhF4hasjsqck4pFSrsOVlm2u3476WfnaFRjsxa53doRD1tLKzcgs+dEKwYIrJtDDdIHllbyZX4X5WhIE19KCz95Ol4r/tt00hsYP4mUEduuMtwKKqgig6oUuBc9WE0FKDqrzx5gpoy85Zw6YB+GW970IyJr4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_OSBPR01MB28696106DAD6B52DF77A46BBF9FB0OSBPR01MB2869jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0bfc0d05-5df4-4036-6b71-08d637606eab X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2018 14:21:03.2307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2326 X-OrganizationHeadersPreserved: OSBPR01MB2326.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-jwsreq-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2018 14:21:10 -0000 --_000_OSBPR01MB28696106DAD6B52DF77A46BBF9FB0OSBPR01MB2869jpnp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Just updated a typo that was pointed out. BTW, the spec has not progressed for a long time. I wonder what can I do to= push it through. Nat ________________________________ =1B$B:9=3DP?M=1B(B: internet-drafts@ietf.org =1B$BAw?.F|;~=1B(B: =1B$BF|MKF|=1B(B, 10=1B$B7n=1B(B 21, 2018 11:17 =1B$B8a= 8e=1B(B =1B$B08@h=1B(B: Nat Sakimura; John Bradley =1B$B7oL>=1B(B: New Version Notification for draft-ietf-oauth-jwsreq-17.txt A new version of I-D, draft-ietf-oauth-jwsreq-17.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Name: draft-ietf-oauth-jwsreq Revision: 17 Title: The OAuth 2.0 Authorization Framework: JWT Secured Authorization Req= uest (JAR) Document date: 2018-10-21 Group: oauth Pages: 27 URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-17.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-17 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. 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. The IETF Secretariat --_000_OSBPR01MB28696106DAD6B52DF77A46BBF9FB0OSBPR01MB2869jpnp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Just updated a typo that was pointed out.&nb= sp;
BTW, the spec has not progressed for a long = time. I wonder what can I do to push it through. 

Nat 
=1B$B:9=3DP?M= =1B(B: internet-drafts@ietf.org
=1B$BAw?.F|;~=1B(B: =1B$BF|MKF|=1B(B, 10=1B$B7n=1B(B 21, 2018 11:17 = =1B$B8a8e=1B(B
=1B$B08@h=1B(B: Nat Sakimura; John Bradley
=1B$B7oL>=1B(B: New Version Notification for draft-ietf-oauth-jwsreq= -17.txt
 

A new version of I-D, draft-ietf-oauth-jwsreq-17.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name: draft-ietf-oauth-jwsreq
Revision: 17
Title: The OAuth 2.0 Authorization Framework: JWT Secured Authorization Req= uest (JAR)
Document date: 2018-10-21
Group: oauth
Pages: 27
URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-17.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-17

Abstract:
The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of
these weaknesses, several attacks to the protocol have now been put
forward.

This document introduces the ability to send request parameters in a
JSON Web Token (JWT) instead, which allows the request to be signed
with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
(JWE) so that the integrity, source authentication and
confidentiality property of the Authorization Request is attained.
The request can be sent by value or by reference.




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.

The IETF Secretariat

--_000_OSBPR01MB28696106DAD6B52DF77A46BBF9FB0OSBPR01MB2869jpnp_-- From nobody Mon Oct 22 06:34:45 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C67130EB8 for ; Mon, 22 Oct 2018 06:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 0XOpagkAcaJq for ; Mon, 22 Oct 2018 06:34:34 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 0C6A8130EB3 for ; Mon, 22 Oct 2018 06:34:28 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id y16so45012964wrw.3 for ; Mon, 22 Oct 2018 06:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=S5LPjQpJ4XKdzh2MW4Ey3xrKjzU7o30eZq4OTyGASSw=; b=f+aDtSZloBO/eTLb1VTvCl0Q7QI7K56yzgR8HvgutJ/J0ICTg/UCoRxsn1jrKoSEdu RdseJI/6ArOBQSddeRsBaf6WnMrTj8a2bEhY0yuc6Hh2U/yZfaW6/v8FHTTa/+mV9MhY CUWaJC8VTIiZ3A6FPP/+3pEGifMWMduMP1G47KSbzIEVufuYPl4qJ/qg7Kj6lLuL4c8x QW39o8DYL8Awf9LDfw5o5jnAZQQzyqGKupNQcMcNmI9DeWVh4lDmKyjSW35aCEmX8Vq/ wjAE7Kk6qQLR0h2Df6rNcK/2INGXXKelrxyDNEX0JSz+9LCTXitJ7mNxm6pF58iD08ch XBEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=S5LPjQpJ4XKdzh2MW4Ey3xrKjzU7o30eZq4OTyGASSw=; b=m4nh28JDUNH0IWPXh7cE+8Efa4wuH1/X7cU5m1CBfd/fxivWi3nItSdTQXuK/6pw1K us1pQdR/qBatXg9JO87B8VmijnUJZQh2ivGNtbbqvgfX+ZPhmhZuwWKj3xrOjXk+QT7C mRKewHeflrLNr3JsmE9EjHeHWUsEJn/g/925wB86Wa3yDojlsN3eUAb9C6AeP3t9chKn i3UOIf+UM65hif/FzqRxKmV8+iANFiBWcXcFEYXX6FtscOBkdBpU2h2GRangnd7PHG2m NN0drp4C5pMzw969bh9/mH+BiJtkV/OcSsCQBFHOyrCRK20Bk1kDn2OTipgqdQ7aNnT5 LyEg== X-Gm-Message-State: AGRZ1gJubtLLt3U3ws97hG2F8SDhUIfH4SZpyLq9/UQCudu41q2Jlal2 aW+bgDI5Rf4mQ6Sy55hfys4ha6Z2ke2ojYn4ppDh0pSyHjc= X-Google-Smtp-Source: AJdET5eF1g1sarYfn7eJPC8o52fNbLUqAOsgTgaduDqoNyYEAEoESZiFYI7ydI6pAbypDutcAeswocHYqo/MSk4iSUc= X-Received: by 2002:a5d:6944:: with SMTP id r4-v6mr9354437wrw.197.1540215266110; Mon, 22 Oct 2018 06:34:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 22 Oct 2018 09:35:35 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000d071e90578d14f33" Archived-At: Subject: Re: [OAUTH-WG] IETF103 OAuth Final Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 13:34:44 -0000 --000000000000d071e90578d14f33 Content-Type: text/plain; charset="UTF-8" All, One more change to the agenda: switching draft-ietf-oauth-token-binding and draft-hevroni-oauth-seamless-flow Here is a link to the latest agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-oauth 9:00-11:00 Monday Morning session I Chairs Update 10min Torsten Lodderstedt - draft-ietf-oauth-security-topics 30min - draft-ietf-oauth-jwt-introspection-response 30min - openid-financial-api-jarm-wd 15min Hannes Tschofenig - draft-ietf-oauth-pop-key-distribution 20min Brian Campbell - draft-ietf-oauth-token-binding 15min 11:20-12:20 Tuesday Morning session II Brian Campbell - draft-ietf-oauth-resource-indicators 15min - draft-ietf-oauth-mtls 5min - draft-ietf-oauth-token-exchange 5min Dick Hardt - draft-ietf-oauth-reciprocal 10min - draft-hardt-oauth-distributed 10min Omer Levi Hevroni (remote) - draft-hevroni-oauth-seamless-flow 15min Regards, Rifaat & Hannes On Fri, Oct 12, 2018 at 1:25 PM Rifaat Shekh-Yusef wrote: > All, > > Here is our final agenda for Bangkok: > https://datatracker.ietf.org/meeting/103/materials/agenda-103-oauth-02 > > 9:00-11:00 Tuesday Morning session I > > Chairs Update 10min > > Torsten Lodderstedt > - draft-ietf-oauth-security-topics 30min > - draft-ietf-oauth-jwt-introspection-response 30min > - openid-financial-api-jarm-wd 15min > > Hannes Tschofenig > - draft-ietf-oauth-pop-key-distribution 20min > > Omer Levi Hevroni (remote) > - draft-hevroni-oauth-seamless-flow 15min > > > 11:20-12:20 Tuesday Morning session II > > Brian Campbell > - draft-ietf-oauth-resource-indicators 20min > - draft-ietf-oauth-token-binding 20min > - draft-ietf-oauth-mtls 10min > - draft-ietf-oauth-token-exchange 10min > > > Regards, > > Rifaat & Hannes > > > --000000000000d071e90578d14f33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

One more change t= o the agenda: switching=C2=A0draft-ietf-oauth-token-binding and draft-hevroni-oauth-seamless-flow

Here is a link to the latest = agenda:

9:00-11:00	Monday Mo=
rning session I

Chairs Update                                       10min

Torsten Lodderstedt
- draft-ietf-oauth-security-topics                  30min
- draft-ietf-oauth-jwt-introspection-response       30min
- openid-financial-api-jarm-wd                      15min

Hannes Tschofenig
 - draft-ietf-oauth-pop-key-distribution            20min

 Brian Campbell
- draft-ietf-oauth-token-binding                    15min=20


11:20-12:20	Tuesday Morning session II

Brian Campbell
- draft-ietf-oauth-resource-indicators              15min
- draft-ietf-oauth-mtls                             5min
- draft-ietf-oauth-token-exchange                   5min

Dick Hardt
- draft-ietf-oauth-reciprocal                       10min
- draft-hardt-oauth-distributed                     10min

Omer Levi Hevroni (remote)
- draft-hevroni-oauth-seamless-flow                 15min

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

=



On Fri, Oct 12, 2018 at 1:25 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

Here is= our final agenda for Bangkok:

9:00-11:00	Tuesday Morning session I

Chairs Update                                       10min

Torsten Lodderstedt
- draft-ietf-oauth-security-topics                  30min
- draft-ietf-oauth-jwt-introspection-response       30min
- openid-financial-api-jarm-wd                      15min

Hannes Tschofenig
 - draft-ietf-oauth-pop-key-distribution            20min

Omer Levi Hevroni (remote)
- draft-hevroni-oauth-seamless-flow                 15min


11:20-12:20	Tuesday Morning session II

Brian Campbell
- draft-ietf-oauth-resource-indicators              20min
- draft-ietf-oauth-token-binding                    20min
- draft-ietf-oauth-mtls                             10min
- draft-ietf-oauth-token-exchange                   10min

<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">Re= gards,
 Rifaat & Hannes

--000000000000d071e90578d14f33-- From nobody Mon Oct 22 07:55:33 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6542612870E for ; Mon, 22 Oct 2018 07:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 4UpHezEPXQBZ for ; Mon, 22 Oct 2018 07:55:25 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C685F126BED for ; Mon, 22 Oct 2018 07:55:24 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 193-v6so10669853wme.3 for ; Mon, 22 Oct 2018 07:55:24 -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=lsYFiZkqCAa2Nuaus3llL+paLi/INZN+Wll9345L7hk=; b=rWikIf8leOXs2crklnJMaUHt3gt3kaXDHuKzgLIdHJ3TTNMSxlLB0cldeMVPIj57pd YGH+O73LuUXYDdCW7jC4EaNFfvi8UwhcWpHAIjBH4lXmuO/qtfB2zlQISXSL0FfBIWJr ZLS1fg9EoDlsG6jD8hS4ne4nwSA+T1+n5OJBNxKlY4onj8da1RFZkvzqoxC5ZoOySo81 PEMxhuIxqyctfstXk5adHy6B7abqLqimMB2uTBg9VagJdeH5boTHO7n1nDEVSVGMiQYG DpMVPHpfzN/ixTQkAPLml68Okwh7gGPIAvfN5KxW06NEZAj7rs5yim1yAMh560hUI5Pb CIkg== 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=lsYFiZkqCAa2Nuaus3llL+paLi/INZN+Wll9345L7hk=; b=bd9B0W3bQGqDNzPVJ2wJDozSJzpzcNeuNw1FCB8XqnkGiSDmI54iaIuLwSxzuuLggu +RD7PvmBtZoAVzer51BVVpCLIZDYhsmD17z7pPWnQ9cevp2LiQrKM8OAdGsyLMBcxveH G5BxETazNp5txjFY52rVVVaMNJQyPv/9LYBlbUsRXpKK29nVkb8HpFnc2O3qhZ/sXyqC AhVIxgEN/36wGj5ut9E90Q44Z8q3DNAkiuFeqTGXlN9aAlX5AuxB6ZI5MIaongyfOUTn 1Lq4ylIleG0/3JcyYqQ8E8pWJYCbnGLqvYjh6mN+WernAqciLCA5fGe422vZ2vNpS0SI TbFg== X-Gm-Message-State: ABuFfogdjTEUDNQ3nfvnkVI72qVv+yuB4f8Zebhh0gw05QkUnnpZ4pWu CFdemLV9ksML1qRapGp5SeE54uqa0MlC8tx92zElnqTBNcA= X-Google-Smtp-Source: ACcGV60bWcKseqax2GATxZdw2YjEJpfim3d2YFxA+2KXD95gJP2kk6/6GLv+NscZt6lCM0wd47DZqA9AfMLouoOEm5g= X-Received: by 2002:a1c:2746:: with SMTP id n67-v6mr15979065wmn.116.1540220123066; Mon, 22 Oct 2018 07:55:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 22 Oct 2018 10:56:32 -0400 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="0000000000004fc7430578d271d5" Archived-At: Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:55:27 -0000 --0000000000004fc7430578d271d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Meeting is cancelled today because of the IIW this week. Regards, Rifaat & Hannes On Wed, May 16, 2018 at 1:39 PM Hannes Tschofenig wrote: > Hi all, > > > > Rifaat and I will again dial into the Webex next Monday to hear whether > someone of you has anything to discuss/report/suggest/=E2=80=A6. > > > > Ciao > Hannes & Rifaat > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --0000000000004fc7430578d271d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Meeting is cancelled today because of the IIW this week.
Regards,
=C2=A0Rifaat & Hannes
<= br>
On Wed, May 16, 2018 at 1:39= PM Hannes Tschofenig <Hann= es.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

Rifaat and I will again dial into the Webex next Mon= day to hear whether someone of you has anything to discuss/report/suggest/= =E2=80=A6.

=C2=A0

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--0000000000004fc7430578d271d5-- From nobody Mon Oct 22 08:09:09 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832841298C5 for ; Mon, 22 Oct 2018 08:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx1snDAlqcBf for ; Mon, 22 Oct 2018 08:09:05 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40087.outbound.protection.outlook.com [40.107.4.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B015C126BED for ; Mon, 22 Oct 2018 08:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gsM9dJV24Yt0FYOMYVNwtnmjduEXcogjyqoJfqktW3g=; b=msDet0R9ySlduDQTWpZ0NAWvISMTZjXKtfPaLmpefrRJmWJpSPTTfcWniicyM0QNITRCvG5xHY4CJtQsXI0hFp4+OXgHl4Mkfc35ILY0hfv+XINj4Vk/gGqQ0kVWH7t0fxVNlI0WbhjcBmdeWLBafABOZlKGttFdq8HEWKHIBwo= Received: from AM5PR0801MB2097.eurprd08.prod.outlook.com (10.168.158.151) by AM5PR0801MB1700.eurprd08.prod.outlook.com (10.169.246.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.29; Mon, 22 Oct 2018 15:09:02 +0000 Received: from AM5PR0801MB2097.eurprd08.prod.outlook.com ([fe80::15e6:1b13:9bae:f7a2]) by AM5PR0801MB2097.eurprd08.prod.outlook.com ([fe80::15e6:1b13:9bae:f7a2%9]) with mapi id 15.20.1250.028; Mon, 22 Oct 2018 15:09:02 +0000 From: Hannes Tschofenig To: Rifaat Shekh-Yusef CC: oauth Thread-Topic: Meeting Invite for the OAuth WG Virtual Office Hours Thread-Index: AQHUahdr0JnNNYa26kKhsOi4XEYVI6UrXfug Date: Mon, 22 Oct 2018 15:09:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [50.225.178.238] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0801MB1700; 6:nu56n2scidE2UGKPa4wQjEN/FDEF5C4hPTz0aE7ZbhvyzFc9AAh3PjONEDOcszcheGPEP5juvCoF/yWhYQXOjjuKIxB3gkk9wDr3opXGFztXtPDqyu60Tbf7u2A1Hd8NfFqUOS60ohLg/nxIkHoSqCZbdzQx4TiMiT4ZV5E8TcA3PaA6ufH2U+zaFRhhRkFQ3Q/t3vX7zf3IKGDjSsaksgVA59YSt2K90SV2wS/D1Lux+QdYa0oNWz3Rr10fASnw9Fe73BxWYtFo/aHAoQTjKlYx07nN/8C8zlFyh/m4VboWtRMK3XEgWiqBlbdoOj1oVV2rbCn7tAbO0K9x1LtVbQdbSAfuWnPNh+iI03X+uSZwAVCdO2BXfOVBAGaQ0ec/YK8Fw/WWnii2qXlfbjMvoH4NQpsYz1dnPyf+hD57ip7+unRqyq7fCIIinbC1QYl1Pa+cOeAbgBo/6cY041xx4A==; 5:847Flkb7jHlB/34rB0BUnO45VwHZglIlkLbMLN0mO3zPU8krCBJ+QzCfvtDeGN10Hhik8Do9CaqXyTOwADGme6P7sKa4oh3sXDcfJbvtKPce20LnhLJuixm4FrFCNvbvB3V5tBe2RzYPtWd+FM7LbPg9mW3qjEZzSVwQivcb6cQ=; 7:Mq0q620n4VvRY3j3iClPcKhTnndIAxjZLzCyrD98l0aCJ0PFLfHjHRGjQ8YyzRTioKQ5Mg3WaeZTA48fdnmSgflOkLNaUdiseafA2tK1vSUJvO8eLEfns/BEXV3vBeOGgRLDjlnc7WSmDPH/j5DEzVAmNee3EbZYIV9YNOqL1N6SSSnJRI8QHzjh4hHRLHWKPsM5tgZ9VOEmYBQDfJNE2geC58Phw6bgkFGj3SMiuisHfNheYuuPyfrKfzM8eScI x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 13d896f6-4d5d-434e-f5ad-08d638304d44 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM5PR0801MB1700; x-ms-traffictypediagnostic: AM5PR0801MB1700: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(180628864354917)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM5PR0801MB1700; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0801MB1700; x-forefront-prvs: 08331F819E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(366004)(376002)(346002)(396003)(40434004)(38314003)(199004)(189003)(53754006)(39060400002)(102836004)(229853002)(71200400001)(6246003)(53936002)(11346002)(486006)(53546011)(71190400001)(316002)(6506007)(14444005)(2906002)(5024004)(256004)(7696005)(476003)(446003)(14454004)(86362001)(76176011)(72206003)(81156014)(81166006)(105586002)(68736007)(99286004)(478600001)(26005)(8936002)(74316002)(6306002)(186003)(5250100002)(236005)(33656002)(9686003)(7736002)(8676002)(6916009)(54896002)(106356001)(6436002)(4326008)(5660300001)(66066001)(97736004)(25786009)(2900100001)(790700001)(6116002)(3846002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0801MB1700; H:AM5PR0801MB2097.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: EwFS8Vh8+UaT7/EU2660MC3gsd8wxKsQ8uDtTmcTI50qN4/7CoK9ddz5f+4JIAgAGEHRSV16DBbNLX8OE46JWswDmhDXABABlG8d8tVOL5d3z2CxyEooPtUVp55zjlWGO2H6FE0mNnqtmixd5AT34YVOcRybiWy9lTo7yBtpEgAZsoeVfZR6+HV5Msza28TZYDmeSErMjLm5PvyJTxHOMk/kaUFzrO12r+2knNzPhA+WnqLbxdkGXJSlwoxDD9syQ+TLXgtAIHrMTy4+hfHu7XfBpmtVdz25ViX+noX2lsxukKVr+dtI/d97/OLK/m1+bZohn1r+k7iw/xafalaKyZBachmh/XxpC2EPdO7f7PE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0801MB2097E285A68F5BF0EABCC545FAF40AM5PR0801MB2097_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13d896f6-4d5d-434e-f5ad-08d638304d44 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2018 15:09:02.4813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1700 Archived-At: Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 15:09:09 -0000 --_000_AM5PR0801MB2097E285A68F5BF0EABCC545FAF40AM5PR0801MB2097_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRkaW5nIHRvIHRoZSBwb3N0IGZyb20gUmlmYWF0OiBJIHdpbGwgYmUgYXQgdGhlIElkZW50aXR5 IElkZW50aXR5IFdvcmtzaG9wIGFuZCBoYXBweSB0byBjaGF0IHdpdGggeW91Lg0KDQpDaWFvDQpI YW5uZXMNCg0KRnJvbTogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+ DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjIsIDIwMTggNzo1NyBBTQ0KVG86IEhhbm5lcyBUc2No b2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBNZWV0aW5nIEludml0ZSBmb3IgdGhlIE9BdXRoIFdHIFZpcnR1 YWwgT2ZmaWNlIEhvdXJzDQoNCk1lZXRpbmcgaXMgY2FuY2VsbGVkIHRvZGF5IGJlY2F1c2Ugb2Yg dGhlIElJVyB0aGlzIHdlZWsuDQoNClJlZ2FyZHMsDQogUmlmYWF0ICYgSGFubmVzDQoNCk9uIFdl ZCwgTWF5IDE2LCAyMDE4IGF0IDE6MzkgUE0gSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2No b2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToN CkhpIGFsbCwNCg0KUmlmYWF0IGFuZCBJIHdpbGwgYWdhaW4gZGlhbCBpbnRvIHRoZSBXZWJleCBu ZXh0IE1vbmRheSB0byBoZWFyIHdoZXRoZXIgc29tZW9uZSBvZiB5b3UgaGFzIGFueXRoaW5nIHRv IGRpc2N1c3MvcmVwb3J0L3N1Z2dlc3Qv4oCmLg0KDQpDaWFvDQpIYW5uZXMgJiBSaWZhYXQNCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCklNUE9SVEFOVCBOT1RJQ0U6IFRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk byBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_AM5PR0801MB2097E285A68F5BF0EABCC545FAF40AM5PR0801MB2097_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWRkaW5nIHRvIHRoZSBwb3N0IGZyb20gUmlmYWF0OiBJIHdpbGwgYmUgYXQgdGhl IElkZW50aXR5IElkZW50aXR5IFdvcmtzaG9wIGFuZCBoYXBweSB0byBjaGF0IHdpdGggeW91Lg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmlmYWF0IFNoZWtoLVl1 c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBPY3RvYmVyIDIyLCAyMDE4IDc6NTcgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2No b2ZlbmlnICZsdDtIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTWVl dGluZyBJbnZpdGUgZm9yIHRoZSBPQXV0aCBXRyBWaXJ0dWFsIE9mZmljZSBIb3VyczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lZXRpbmcgaXMgY2FuY2VsbGVkIHRvZGF5 IGJlY2F1c2Ugb2YgdGhlIElJVyB0aGlzIHdlZWsuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0ICZhbXA7IEhhbm5lczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1h eSAxNiwgMjAxOCBhdCAxOjM5IFBNIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWls dG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIGFsbCwNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+UmlmYWF0IGFuZCBJIHdpbGwgYWdhaW4gZGlhbCBpbnRvIHRoZSBXZWJleCBu ZXh0IE1vbmRheSB0byBoZWFyIHdoZXRoZXIgc29tZW9uZSBvZiB5b3UgaGFzIGFueXRoaW5nIHRv IGRpc2N1c3MvcmVwb3J0L3N1Z2dlc3Qv4oCmLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5DaWFvPGJyPg0KSGFubmVzICZhbXA7IFJpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLA0KIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Us IG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlv dS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55 IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5 IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_AM5PR0801MB2097E285A68F5BF0EABCC545FAF40AM5PR0801MB2097_-- From nobody Mon Oct 22 14:12:56 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D11DB130E8D; Mon, 22 Oct 2018 14:12:39 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154024275980.13622.6841285736104765237@ietfa.amsl.com> Date: Mon, 22 Oct 2018 14:12:39 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 21:12:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Incremental Authorization Author : William Denniss Filename : draft-ietf-oauth-incremental-authz-01.txt Pages : 9 Date : 2018-10-22 Abstract: OAuth 2.0 authorization requests that include every scope the client might ever need can result in over-scoped authorization and a sub- optimal end-user consent experience. This specification enhances the OAuth 2.0 authorization protocol by adding incremental authorization, the ability to request specific authorization scopes as needed, when they're needed, removing the requirement to request every possible scope that might be needed upfront. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-incremental-authz-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 23 14:15:33 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD78130DEC; Tue, 23 Oct 2018 14:15:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154032932506.31373.13237143120397412833@ietfa.amsl.com> Date: Tue, 23 Oct 2018 14:15:25 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 21:15:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution Authors : John Bradley Phil Hunt Michael B. Jones Hannes Tschofenig Mészáros Mihály Filename : draft-ietf-oauth-pop-key-distribution-04.txt Pages : 17 Date : 2018-10-23 Abstract: RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 23 14:19:25 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD22C130DEC for ; Tue, 23 Oct 2018 14:19: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBQypDoPOlel for ; Tue, 23 Oct 2018 14:19:21 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10068.outbound.protection.outlook.com [40.107.1.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38412130DC7 for ; Tue, 23 Oct 2018 14:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s1QgrKuQANbU5IbE7NvFheTP6jiHLKvj+2ATbXRkJOw=; b=r5h+OfIitsxRhZBnjgrsdejE+MGqQP68zndJS+cdQmZq3+VTGQioEF54YdGNlOUJZO7gNxOLSaoro+CBf8D1fjF+iKzdE57IgqDQbdSk2tSw6H/jlKzZEVp+hjFYo+301X4Mg8qGz4nYJHZfZlCwDtGvRc087PiCsgStfn996SI= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1344.eurprd08.prod.outlook.com (10.167.198.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Tue, 23 Oct 2018 21:19:17 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c%2]) with mapi id 15.20.1273.014; Tue, 23 Oct 2018 21:19:17 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: draft-ietf-oauth-pop-key-distribution-04 Thread-Index: AdRrFbjk8H/jJ0g6SqSNJ6nGbsSaoQ== Date: Tue, 23 Oct 2018 21:19:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [64.71.18.60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1344; 6:yh8UujyfknRZZB9BYdl2LA64OHcyAqPNZ4mTJ/EXj9KRql1WYpFT217khG1FgzBlpzYj5eaTsdqMNrgQDKJK8jlahocSGFBr8CJodJCvS5/R0Pjg0NKisxBHkgbaMMh+mnm1IdrF0antFEY2GG4wZUiy+WR67v1d8LMMSa4OJUiq2zxCLoqmWgf9ZFDciamjdiBfV5+6290K+j3GsRtYxb2QZygNVTfEjHIlgOWIzILiFlFU9oq9wxLIWqyogfko7kVfOgok0cvFP/fwDH26hOHUNB+QL9g5vQCbfJC8VgoO0LxIzk+ehIc6hRpbnfxYhHD6RBe3Kphhk5YgImeD4NVqcYc3NCvD6GnZWWc8Y6howClv8/Oh8taZ+TN5DACEYq2dF4pqEbUJ8p8AQZwIPtEtwTGrf94Ov72XIWlg9l4M7Q5TVM8g1PNJCoiKfDPA8yzpOPIBg4NEvhn5XY8CzA==; 5:yet/gKnp2xqWDarhrbw2ju4+aIKeqhcnLvE06+80BJ7+EJSe1eU38LvMdZiN31+leeQCBc06D3UFlEhz+moqAJtMVecQ11eZ2sFdNLdVLNkfRZWW9HnkM9Kn+uElFTWE68kSOTq4cH9yYFQ4pJT2hxSjcrS1wZnMQKlnTg9+YUU=; 7:1VT6fyDql7iOQeHV5FoE3Iq5TMlQdf3O42Vr+kWCpn9cVENYt3C8Xp4PdVXHgguyH1moacx1CG1YO/lPMeDNNPPPv6VkOU9hNM11SKQ4GOet4IgpwIJc/bs2NOqtpu05Nf4LG4krjQwMrItTLKI8feoQ3KPr9hOeFYhpqy+qYAiVL47gDFwYkw0kQZhXREqEDHmzeejcD6KL4t+oHUrkBFzJcjmKtNs9C10exgxIGeMsvdnPWaBJUW/5vrHlwSi+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ca3a3bf1-fd8d-4b05-2882-08d6392d30e8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1344; x-ms-traffictypediagnostic: VI1PR0801MB1344: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1344; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1344; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(376002)(136003)(53754006)(40434004)(199004)(189003)(6916009)(74316002)(105586002)(106356001)(102836004)(26005)(6506007)(606006)(790700001)(7696005)(3846002)(99286004)(966005)(6116002)(66066001)(14454004)(72206003)(68736007)(2900100001)(33656002)(7736002)(6436002)(53936002)(5660300001)(55016002)(5250100002)(54896002)(236005)(9686003)(97736004)(2906002)(486006)(316002)(71200400001)(81166006)(6306002)(476003)(186003)(14444005)(478600001)(5024004)(25786009)(256004)(86362001)(81156014)(8936002)(71190400001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1344; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: zmzuij0/mBecVCOuwCXxAsacpKDk0urXxpJQ6wy6hAfPOyx63vUUuC+m/1CKHT8UH7QaW1CZsRFaLRo6i2nV48cHpixbMFtsbLEsoPrTmBWj6pVkeJOdhuUG9pcgrnWwHFuV3eq4txsBP1KDcq2WDHQHarNX6s49+Wf7zT1+M0Xbs04xqOmvWoaEcn2Wa2hdgR/6lU9wpzo02b7AV0eEB1dsSF+pqnuS2Qf4RGULpLejfAWuPBUfjCfDxCFGcLSbNovjxl8C6NypViyTOSSi5fOb4/gfAyVtZhRHulyIkdYWmIh/ygYOijxnBgSu3W/vQzeLvAqiZTquFdZbMXTg/2YwvmX/fHSTf1wOOyVa7iw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21127B2B6CBA397D1E388CCAFAF50VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca3a3bf1-fd8d-4b05-2882-08d6392d30e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 21:19:17.4930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1344 Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 21:19:24 -0000 --_000_VI1PR0801MB21127B2B6CBA397D1E388CCAFAF50VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I refreshed the PoP key distribution document today, see https://tools.ietf= .org/html/draft-ietf-oauth-pop-key-distribution-04, in an attempt to get th= e document inline with the agreements we made at the Montreal IETF meeting,= the Resource Indicators draft, and the work happening in ACE. Thanks to Mike for going through the draft with me and for spotting several= copy-and-paste mistakes. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21127B2B6CBA397D1E388CCAFAF50VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I refreshed the PoP key distribution document today,= see https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-04, i= n an attempt to get the document inline with the agreements we made at the = Montreal IETF meeting, the Resource Indicators draft, and the work happenin= g in ACE.

 

Thanks to Mike for going through the draft with me a= nd for spotting several copy-and-paste mistakes.

 

Ciao
Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21127B2B6CBA397D1E388CCAFAF50VI1PR0801MB2112_-- From nobody Wed Oct 24 15:23:30 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AEA12F18C for ; Wed, 24 Oct 2018 15:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUSnh0BACjRz for ; Wed, 24 Oct 2018 15:23:26 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 7ECFB12D4EC for ; Wed, 24 Oct 2018 15:23:26 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id u21so3550233vsl.6 for ; Wed, 24 Oct 2018 15:23:26 -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=tRAiD0yW6zPfkwjz356ZiA0UuwF/KISUAOT6YHzb+G0=; b=QwbiNeY070+krq/De0PpwGbJf13J50u2KJt90p9qgWVA/bE/sJyWORX2Nn7SCz9l+v ErUfdN1szLpK4NeEPj2KItO9WOO5vSJIqbS8Q7dmw2ehexyEZGMAiLR3DgjCeheOZpSy KT9wA6nLOIydPnVlKK5LofCylkKBFvslJtjergJg4dZLs/SA/Ljq/n3vl+H3D+scNE1w l490j5fPcHdfP7g3GvPz+iu6jyASrxn3bR1v+4dc48lF6LS1xKdZvHeS6ASDgTx44XTm 34KY/MYV0ONLFUyaRxwDzXcgIlD/NzJlImLLmGc+5iUMBnDel/yTtC9lmXgLJwI1VyJ5 0GGg== 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=tRAiD0yW6zPfkwjz356ZiA0UuwF/KISUAOT6YHzb+G0=; b=YxDlB6aUS5WaLE8ITPhcxeVpZXls7LrgqyaDjh2pdzZyMICZnY/un6SB3X7sZIePsn ZdElIsJKBEnN7bPlWsM1Z1o+CH/DqwYzml4zytB9JlIP6xmiKzHQC9Bl9KvCBQ9D0T33 hH3eBlk9h/v+QgoijNm3bqtHDI+Wez/TxSeB0RBsRL+5cw9+NQi4uoxZ5nyN5sqrIc2M BefYctBOSvK4nKXJaqceGX4s0HjM6ZISQ3RhWgWpocQ7joTDxn0kctxnDm3+LAv3TB8w 8gRlpJk2q9pguTZlQUac78uqTGwJnb8kRQ8XGFiSrRtWFjRYPNYPlp2loIbAeRg81EGW N+Bg== X-Gm-Message-State: AGRZ1gLFXaPeBxiMgI28hYduthTyXuUyrN95TAz5uhZzJ2IPgBFyabRn VoDxHmdtCBaq6GohK0Cx9LdiWnji2D+xtYoFQyaSBsU= X-Google-Smtp-Source: AJdET5dy1CIcTClDVsLKbKbakwP1gA2vlslAqyrHNBQvUwmHvrYjqJwcv9ww/O0gqxgHLr3xqz+pr/gNYfn2hcUrFys= X-Received: by 2002:a67:47cf:: with SMTP id b76mr670238vsg.184.1540419805264; Wed, 24 Oct 2018 15:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:37c8:0:0:0:0:0 with HTTP; Wed, 24 Oct 2018 15:23:24 -0700 (PDT) In-Reply-To: References: From: Yong Ali Date: Wed, 24 Oct 2018 15:23:24 -0700 Message-ID: To: "oauth@ietf.org" , newsletter@site24x7.com, Yong Ali Iphone , Yong Ali Iphone Content-Type: multipart/alternative; boundary="0000000000004c3e2c057900ef34" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 120, Issue 16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 22:23:28 -0000 --0000000000004c3e2c057900ef34 Content-Type: text/plain; charset="UTF-8" Kamis, 25 Oktober 2018, menulis: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > --0000000000004c3e2c057900ef34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Kamis, 25 Oktober 2018, <oauth-request@ietf.org> menulis:
Send OAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.or= g

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

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

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
--0000000000004c3e2c057900ef34-- From nobody Thu Oct 25 16:08:32 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873611200D7 for ; Thu, 25 Oct 2018 16:08:30 -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 wXVcV6V643YW for ; Thu, 25 Oct 2018 16:08:28 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFD9127B92 for ; Thu, 25 Oct 2018 16:08:27 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id c6-v6so5860917iob.11 for ; Thu, 25 Oct 2018 16:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t2ZLJiz2Ea9znClVW+VCl/mOX0r+VM5JMr7p0afnvwc=; b=D/bGCHU21bSaC2JhL9eCYe8PkHveXfBlcu8ZouYq5yCi6VS58fY5UAIdb+xC4Ao5eb hgOIuCSFZ3DcwQ7Xa09TMydOEGSbr1u2j04+LFb9uFBvbvjsr53cUZU1j45vZDsZ/w9P lmTvfzd/KaW94yUoULuMa1zDK8bynsZ9io5a4= 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=t2ZLJiz2Ea9znClVW+VCl/mOX0r+VM5JMr7p0afnvwc=; b=iHmHR3MRPxuFsixr2fJ9nJFi+uM3Ndvp91gMLJiAW6Zvxw56q8SuYNUKYF0bdELIgB iZBJmSclZ96Uc9QW9rq1QnzK0F899tVyWynTvKg0tGBL2BNcaDUNVcL3tSjfSuOTnyiI nd8BLlsCIQlq0v7nfrc66W37Yg/Bnll3Qoo0p8cwd02Ljiz4FLw2Q/q1mqV39kKVSBls aId3fNWv1TD5Z3etj9SByt6Cm/xQAbFw3xXp8RDFuKmAqhoxVCTTY7TeSArZgwPu8rNc idvnv+TR+UgHb6FSBQ+UQ52qll7D+cCcLY5GA91n8+OdwqVRh2KE2KyDyPTxfNxwiqqb 2hcQ== X-Gm-Message-State: AGRZ1gIABimam3ePRSY4936vcv8X0YBVRl3LktKez8KptlOApPIHjir8 psLz1LtdsM9WZI/cTiuSbSP7uVXYmwqLW5BGmslpz85fLhzLOrZRv7rdODLOTPqEBA2ZnBhKWTp ROvQy8KkJIN1PQA== X-Google-Smtp-Source: AJdET5cM6pDbk8JovSZaKSD21N7bPOwYfvqByXTlb1GLv7XEw0V++qzTwJ0uSzp40B2b0wMPOPYl1YXn/go3XlLh9iw= X-Received: by 2002:a6b:710b:: with SMTP id q11-v6mr707931iog.138.1540508906874; Thu, 25 Oct 2018 16:08:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Thu, 25 Oct 2018 17:07:59 -0600 Message-ID: To: Evert Pot Cc: oauth Content-Type: multipart/alternative; boundary="0000000000002b0d6d057915ae54" Archived-At: Subject: Re: [OAUTH-WG] draft-hardt-oauth-distributed suggestions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 23:08:31 -0000 --0000000000002b0d6d057915ae54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nearly a month later (sorry) replies to some of the comments/questions are inline below. On Fri, Sep 28, 2018 at 9:11 PM Evert Pot wrote: > I read the Distributed OAuth draft, and I have a few comments and > questions: > > The draft defines 2 new link relations. "resource_uri" and > "oauth_server_metadata_uri". However, the underscore is actually > invalid[1]. > Well that's definitely a problem that needs to be fixed. Doh. Thanks for pointing that out! > On the IANA Links Relations registry[2], most existing link relations > use dashes, or occasionally camel-case as a separator. I would suggest > using dashes. I also don't think that the _uri postfix is needed, as the > implication of any link is that it points to a uri. > > A second question I have is related to the resource_uri. The way I > expect this specification to be used, is that a client will attempt to > access a resource. When accessing it will be met with a 401 > Unauthenticated along with meta-data that will help the client > authenticate. > > To me the implication of this is that the resource_uri is the uri that > the client tried to access. A more appropriate existing link relation > might therefore be the 'self'. However, why would a resource server ever > need to communicate what it's own url is? The explanation I can think of > is that this is a mechanism for a resource to suggest a different > resource to authenticate for. > > I'm curious what the use-case for this is. Regardless, I feel that the > "resource_uri" name is going to be rejected on the basis that 'Resource > Uri' is a generic concept on the web, but this draft assigns a very > specific oauth2 meaning to it. > The idea or use-case behind the "resource_uri" link relation (and this likely needs to be explained better in the document and clearly the name needs to change) is that it is likely to be a more general URI than the specific request was made to. Like a base URL for the whole application, API, or set of protected resources. So, for example, both a request to https://api.example.com/someapp/stuff/abc123 and https://api.example.com/someapp/stuff/xyz789 might get a 401 with resource_uri link relation value of ;. Or a requests to https://resources.example.com/some/deeper/path/here and https://resources.example.com/things might both get a 401 with resource_uri link relation value of ;. So 'self' isn't quite right for it. > > I also have a question: > > One thing I've missed from using OAuth2-powered services over HTTP Basic > / Digest, is the ability for a browser to handle login. The idea that a > browser can potentially do all the steps required, means that a user > could potentially hit a resource server directly and browse it > interactively without requiring a non-browser client. I think this > concept is really powerful, and Distributed OAuth is a good step in that > direction. > > The piece that's missing though is that using the current OAuth2 > framework, a generic client would still need to have a client_id. > > I don't fully understand the security implications of this, but could > this specification potentially be expanded so that the WWW-Autenticate > challenge can optionally also include a client_id? > > The way I see this work is that a browser could grab it and attempt > using it with the implicit flow. > > I did some experimentation with this, and I believe that this feature > could actually be built as a web extension, but it will only work in > Firefox as Chrome does not give web extensions access to the > Authorization header. > > If there is interest in this idea, I'm happy to help edit the current > draft. > > I do suspect there'd need to be a serious look at the security implications of something like that. And my sense is that it is beyond the scope of the distributed oauth document. Evert > > [1]: https://tools.ietf.org/html/rfc8288#section-3.3 > [2]: https://www.iana.org/assignments/link-relations/link-relations.xhtml > [3]: > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000002b0d6d057915ae54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nearly a month late= r (sorry) replies to some of the comments/questions are inline below.
<= /div>

On Fr= i, Sep 28, 2018 at 9:11 PM Evert Pot <me@evertpot.com> wrote:
I read the Distributed OAuth draft, and I have a few commen= ts and questions:

The draft defines 2 new link relations. "resource_uri" and
"oauth_server_metadata_uri". However, the underscore is actually = invalid[1].

Well that's definitely = a problem that needs to be fixed. Doh. Thanks for pointing that out!
=C2=A0
On the IANA Links Relations registry[2], most existing link relations
use dashes, or occasionally camel-case as a separator. I would suggest
using dashes. I also don't think that the _uri postfix is needed, as th= e
implication of any link is that it points to a uri.

A second question I have is related to the resource_uri. The way I
expect this specification to be used, is that a client will attempt to
access a resource. When accessing it will be met with a 401
Unauthenticated along with meta-data that will help the client authenticate= .

To me the implication of this is that the resource_uri is the uri that
the client tried to access. A more appropriate existing link relation
might therefore be the 'self'. However, why would a resource server= ever
need to communicate what it's own url is? The explanation I can think o= f
is that this is a mechanism for a resource to suggest a different
resource to authenticate for.

I'm curious what the use-case for this is. Regardless, I feel that the<= br> "resource_uri" name is going to be rejected on the basis that = 9;Resource
Uri' is a generic concept on the web, but this draft assigns a very
specific oauth2 meaning to it.

The idea= or use-case behind the "resource_uri" link relation (and this li= kely needs to be explained better in the document and clearly the name need= s to change) is that it is likely to be a more general URI than the specifi= c request was made to. Like a base URL for the whole application, API, or s= et of protected resources. So, for example, both a request to https://api.example.com/someapp= /stuff/abc123 and https://api.example.com/someapp/stuff/xyz789 might get a 401 with r= esource_uri link relation value of <https://api.example.com/someapp/>;. Or a requests to https://resources= .example.com/some/deeper/path/here and https://resources.example.com/things might both get a = 401 with resource_uri link relation value of <https://resources.example.com/>;. So 'self'= isn't quite right for it.

=C2=A0

I also have a question:

One thing I've missed from using OAuth2-powered services over HTTP Basi= c
/ Digest, is the ability for a browser to handle login. The idea that a
browser can potentially do all the steps required, means that a user
could potentially hit a resource server directly and browse it
interactively without requiring a non-browser client. I think this
concept is really powerful, and Distributed OAuth is a good step in that direction.

The piece that's missing though is that using the current OAuth2
framework, a generic client would still need to have a client_id.

I don't fully understand the security implications of this, but could this specification potentially be expanded so that the WWW-Autenticate
challenge can optionally also include a client_id?

The way I see this work is that a browser could grab it and attempt
using it with the implicit flow.

I did some experimentation with this, and I believe that this feature
could actually be built as a web extension, but it will only work in
Firefox as Chrome does not give web extensions access to the
Authorization header.

If there is interest in this idea, I'm happy to help edit the current d= raft.


I do suspect there'd need to be a = serious look at the security implications of something like that. And my se= nse is that it is beyond the scope of the distributed oauth document.
<= /div>

=C2=A0

Evert

[1]: https://tools.ietf.org/html/rfc8288#section-3.3<= /a>
[2]: https://www.iana.org/assign= ments/link-relations/link-relations.xhtml
[3]:

_______________________________________________
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. --0000000000002b0d6d057915ae54-- From nobody Thu Oct 25 20:40:31 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D3212F1A6 for ; Thu, 25 Oct 2018 20:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ8N-G0ikkvs for ; Thu, 25 Oct 2018 20:40:28 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id DFE1712DD85 for ; Thu, 25 Oct 2018 20:40:27 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:e8a1:73fe:aeca:80e2] (unknown [IPv6:2601:282:202:b210:e8a1:73fe:aeca:80e2]) by alkaline-solutions.com (Postfix) with ESMTPSA id 66964315EC; Fri, 26 Oct 2018 03:40:26 +0000 (UTC) From: David Waite Message-Id: <582DF2F1-9A8C-4A80-8A07-7B7151320D10@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B0175D1F-5C66-4092-A7F9-67FA8ED2A603" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Thu, 25 Oct 2018 21:40:25 -0600 In-Reply-To: Cc: oauth To: Evert Pot References: X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OAUTH-WG] draft-hardt-oauth-distributed suggestions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 03:40:30 -0000 --Apple-Mail=_B0175D1F-5C66-4092-A7F9-67FA8ED2A603 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 28, 2018, at 9:10 PM, Evert Pot wrote: >=20 >=20 > One thing I've missed from using OAuth2-powered services over HTTP = Basic > / Digest, is the ability for a browser to handle login. The idea that = a > browser can potentially do all the steps required, means that a user > could potentially hit a resource server directly and browse it > interactively without requiring a non-browser client. I think this > concept is really powerful, and Distributed OAuth is a good step in = that > direction. >=20 > The piece that's missing though is that using the current OAuth2 > framework, a generic client would still need to have a client_id. >=20 > I don't fully understand the security implications of this, but could > this specification potentially be expanded so that the WWW-Autenticate > challenge can optionally also include a client_id? I assume this is the WWW-Authenticate Bearer challenge at the resource. I lean toward reducing the coupling between the resources and the AS to = understanding the access token - how to directly verify it or introspect = it, the meaning of data contained within such as scopes, and so on. This = sort of dynamic specification expands that to needing to state the = issuer (hopefully not raw metadata url) of the issuers it wishes to = receive authorization from - a pretty minimal (and logical) expansion on = the requirements of the resource server for what is being attempted. Having the resource server also maintain metadata on how anonymous = clients should work seems like an unnecessary expansion on resource = server responsibilities. I would say instead: - Expand Dynamic Client Registration (7591) as necessary to meet new = requirements. - Give an anonymous client identifier as part of the AS server metadata = (8414) Having a unique client identifier (or token) per browser may help with = managing security constraints the AS may want to place on anonymous = clients, such as SSO or persistent consent. > The way I see this work is that a browser could grab it and attempt > using it with the implicit flow. For a built-in browser support (especially for a static client_id) it = isn=E2=80=99t clear what a recommendation for the redirect uri would be. = Reducing the requirements placed upon a resource server, I=E2=80=99d = prefer this not be a =E2=80=98dummy resource=E2=80=99 for the browser to = consume rather than routing through. > I did some experimentation with this, and I believe that this feature > could actually be built as a web extension, but it will only work in > Firefox as Chrome does not give web extensions access to the > Authorization header. The other approach I=E2=80=99ve played with for this is using service = workers, although I haven=E2=80=99t gotten far enough to figure out the = UX for user authentication and consent. Is there any feasibility to = having an extension inject a service worker? I suppose this could = conflict with CSP. -DW= --Apple-Mail=_B0175D1F-5C66-4092-A7F9-67FA8ED2A603 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 28, 2018, at 9:10 PM, Evert Pot <me@evertpot.com> = wrote:

<parts answered by Brian>

One thing I've missed from using = OAuth2-powered services over HTTP Basic
/ Digest, is the = ability for a browser to handle login. The idea that a
browser can potentially do all the steps required, means that = a user
could potentially hit a resource server directly = and browse it
interactively without requiring a = non-browser client. I think this
concept is really = powerful, and Distributed OAuth is a good step in that
direction.

The piece that's = missing though is that using the current OAuth2
framework, = a generic client would still need to have a client_id.

I don't fully understand the security implications of this, = but could
this specification potentially be expanded so = that the WWW-Autenticate
challenge can optionally also = include a client_id?

I assume this is the WWW-Authenticate Bearer = challenge at the resource.

I lean = toward reducing the coupling between the resources and the AS to = understanding the access token - how to directly verify it or introspect = it, the meaning of data contained within such as scopes, and so on. This = sort of dynamic specification expands that to needing to state the = issuer (hopefully not raw metadata url) of the issuers it wishes to = receive authorization from - a pretty minimal (and logical) expansion on = the requirements of the resource server for what is being = attempted.

Having the resource = server also maintain metadata on how anonymous clients should work seems = like an unnecessary expansion on resource server responsibilities. I = would say instead:
- Expand Dynamic Client Registration (7591) = as necessary to meet new requirements.
- Give an anonymous = client identifier as part of the AS server metadata (8414)

Having a = unique client identifier (or token) per browser may help with managing = security constraints the AS may want to place on anonymous clients, such = as SSO or persistent consent.

The way I see this work is that a browser = could grab it and attempt
using it with the implicit = flow.

For a built-in browser support (especially = for a static client_id) it isn=E2=80=99t clear what a recommendation for = the redirect uri would be. Reducing the requirements placed upon a = resource server, I=E2=80=99d prefer this not be a =E2=80=98dummy = resource=E2=80=99 for the browser to consume rather than routing = through.

I did some experimentation = with this, and I believe that this feature
could actually = be built as a web extension, but it will only work in
Firefox as Chrome does not give web extensions access to = the
Authorization header.

The = other approach I=E2=80=99ve played with for this is using service = workers, although I haven=E2=80=99t gotten far enough to figure out the = UX for user authentication and consent. Is there any feasibility to = having an extension inject a service worker? I suppose this could = conflict with CSP.

-DW
= --Apple-Mail=_B0175D1F-5C66-4092-A7F9-67FA8ED2A603-- From nobody Sat Oct 27 16:11:09 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65768130DDA; Sat, 27 Oct 2018 16:11:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154068186141.5657.5708171860868071302.idtracker@ietfa.amsl.com> Date: Sat, 27 Oct 2018 16:11:01 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-device-flow-13: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 23:11:01 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-device-flow-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss points. I would still prefer to see a normative requirement for explicit user approval (as opposed to just the descriptive statement that the chance to approve/deny should be offered), but I can understand the sentiment that such a requirement on the UI is not a matter for interoperability and could not be reliably enforced anyway. Original COMMENT section preserved below. Please use the RFC 8174 boilerplate instead of the RFC 2119 one. Section 3.2 The example expires in 30 minutes? That seems longer than needed; wouldn't 5 minutes do? Section 3.3 I agree with directorate reviewer that the MUST NOT requirement for displaying the device_code should justify that requirement by discussing the consequences of exposure. Section 3.5 authorization_pending The authorization request is still pending as the end-user hasn't yet completed the user interaction steps (Section 3.3). The client should repeat the Access Token Request to the token endpoint. I feel like we want to mention the 'interval' here or some other discussion of an inter-request delay. Also, please clarify "reasonable default polling interval", per multiple directorate reviews. Section 5.2 Please clarify the entities involved in "the backchannel flow" that can be MITM'd. Section 5.6 The "short-range" part of a "short-range wireless signal" partially depends on how big the receiver's antenna is. So perhaps we should be careful about indicating that this has more security value than it does. Section 6.1 I'm not sure I understand the usage of "case-insensitive", here -- how would the user have an expectation of case-insensitivity? Perhaps it is better to just say "majuscule" or "upper case" or whatever. From nobody Wed Oct 31 08:33:23 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA6130E2A; Wed, 31 Oct 2018 08:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 0krANyKTfIcP; Wed, 31 Oct 2018 08:33:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE77130DE5; Wed, 31 Oct 2018 08:33:19 -0700 (PDT) Received: from Jude (76.14.1.154) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 31 Oct 2018 08:28:27 -0700 From: Jim Schaad To: CC: 'oauth' Date: Wed, 31 Oct 2018 08:33:09 -0700 Message-ID: <04d301d4712f$08bf8dc0$1a3ea940$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdRxLpIMI5di45SuRsKCd+hvIPbTSA== Content-Language: en-us X-Originating-IP: [76.14.1.154] Archived-At: Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 15:33:21 -0000 As part of looking at the issues of using CWTs for this purpose I did some more reading of the document. I am having a problem with the understanding the reasons for using JWT as opposed to just saying that you are going to use JWS and JWE. There is nothing in this section that I can see that points to a reason to be using JWTs as the carrier. What am I missing? Jim From nobody Wed Oct 31 09:17:45 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A19130DC2; Wed, 31 Oct 2018 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exB9VT61mN34; Wed, 31 Oct 2018 09:17:41 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640120.outbound.protection.outlook.com [40.107.64.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761661293FB; Wed, 31 Oct 2018 09:17: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:X-MS-Exchange-SenderADCheck; bh=D6nGemQzx9hIc33rvJ2TyJbrOdiHWLegR+GWH+u3BKw=; b=fLieGZkrh9Pln/5YaBOaXLDf3fBZOta1s1lXb+MaIEtZ7s2+goE1kr/pdCMRj0socdbaaMOY4zTzIAwS0kKObTEhPiyDKzjpR/ohxGPxTlzJ5BANyXcrNbuHe2LrXhzWb7UlCC+OtmCQwlRAJV0n+6SKUHT651xjWxHFgo5UosM= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0412.namprd00.prod.outlook.com (52.132.149.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1335.0; Wed, 31 Oct 2018 16:17:38 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::adfd:292e:1b8e:cbd]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::adfd:292e:1b8e:cbd%6]) with mapi id 15.20.1336.000; Wed, 31 Oct 2018 16:17:38 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-oauth-jwsreq@ietf.org" CC: 'oauth' Thread-Topic: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq Thread-Index: AdRxLpIMI5di45SuRsKCd+hvIPbTSAABVs7A Date: Wed, 31 Oct 2018 16:17:38 +0000 Message-ID: References: <04d301d4712f$08bf8dc0$1a3ea940$@augustcellars.com> In-Reply-To: <04d301d4712f$08bf8dc0$1a3ea940$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.95.50] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0412; 6:3kQZlF5bUAX2YrATp9+624h6Kld4Kb0gT5rUKUxP4YfQ3DyIMi+4EfaIzvibuEIHbcLMkLLPfb+N2RZg/oZ2VhCepz7kwZyX16ka+xWXnvFt4uvGHZetMP+FfaOuYVUhERFfngNc0mNwCzSyFJ68BCmprqa0u+PTG59GORVodzCAJdoLDVIo/hA7MbvY5oz+7ky58E4GsGoYVFHTzlztlJ/DeJY4GILTBfkcZWXZbLeq+j1ZI2fUp9KpSSCioOojRxlaz58zhX4xJkFSM1hx7KD3Tdw3owCPLfq6WNGhSWBJYEpbIxO8lvkdwn20vouY2SyFvEd+fh9++xCTkeCO+vO90O/KEsG6jwGfICg80gwexzForXCqIYCnoGUm9c4l6XjfzHyIxIlNDbttxjiTEgNmbJeXiezA4zjWb8v7E0N6raRYvllOWwGPWPKrEio1cNQzU2RTybAKdFElRLzgfA==; 5:5diw/8m7lAjJrZuaR1GDknkSvv+xBzXZ2PuSCc+eZQFJu+sKLuPRJR3g7x0C+iWrAJFz9JFkfQgQpDSdgzfd8pQ2ZIW365h7R1ub5Z/BfwDtQPsa5cp+bt8rn4ODFZ5xLLXTLXSwGjbj3A18TwHR6JkE90x5VC7A4xIfHiHmqWA=; 7:rpy8iVbEiidSb1OlquaXKjWbvewy36/vDKQNdsiNfI6pZMnjlOBwhxZRTP5hoaiiAcXfTY2VsdieYw8Vggq9+LEs+Fi7MjlMRQ/Uqb5+/VoVH432/JW4usTc4HvobTeyrl/KC/huRFbHbMouSmQIMA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bacf0725-2e40-4c1e-6be5-08d63f4c605c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MW2PR00MB0412; x-ms-traffictypediagnostic: MW2PR00MB0412: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231382)(944501410)(52105102)(2018427008)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:MW2PR00MB0412; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0412; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(376002)(346002)(366004)(189003)(199004)(13464003)(105586002)(81156014)(8990500004)(81166006)(86362001)(53936002)(8676002)(54896002)(9686003)(236005)(229853002)(6436002)(6306002)(2900100001)(316002)(8936002)(606006)(2906002)(106356001)(97736004)(55016002)(68736007)(110136005)(10090500001)(790700001)(6116002)(3846002)(2501003)(22452003)(5250100002)(33656002)(256004)(71200400001)(21615005)(71190400001)(74316002)(14444005)(7736002)(14454004)(6506007)(5660300001)(7696005)(446003)(53546011)(478600001)(72206003)(186003)(486006)(102836004)(10290500003)(26005)(76176011)(966005)(4326008)(99286004)(476003)(25786009)(6246003)(66066001)(86612001)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0412; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2KOk/6eY3gzWf+2fpxWF05ye/tqb8knPqACUg/gDvBR46JiH5+W3gPE86/QBAZzxgilUQiR8a7+k7UHPacGTHT+3EkcSeef3eG2AquZ2eLC6oB+hSVJ/LNCbFja3YsFZOaLx5ElULDlxHnhREelSIcPWw+jMAv85FakAYgJkjNOApYRpy9kZ/gG8h+7k6U+nCwziqZJy9UE3T+KC0NRxSoLLZn6eEQQggUqTPAFOWA3CiXU4T7fKVhddUgo+0OczAz9tPYBH2WOtlJOttfohaF/F36+BfjTyNOnf25v5yTkuDqWqslPCtVtAC6BVs0ary2tAybk0jpFHaX9qCkgg+mdpFkfvFNV8Q8Z3h6mvjNk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0298547452BD260483C0CC50F5CD0MW2PR00MB0298namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: bacf0725-2e40-4c1e-6be5-08d63f4c605c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2018 16:17:38.4666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0412 Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 16:17:43 -0000 --_000_MW2PR00MB0298547452BD260483C0CC50F5CD0MW2PR00MB0298namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JWT defines a number of standard claims that are used in this application, = including "iss" (issuer), "aud" (audience), etc. Making the requests a JWT= allows code reuse, rather than having an application-specific signed reque= st representation that has many of the semantics and fields of a JWT anyway= . It's also worth noting that this practice has been a standard since 2014. = OpenID Connect Core standardized the OAuth signed request format in https:/= /openid.net/specs/openid-connect-core-1_0.html#JWTRequests. The draft-ietf= -oauth-jwsreq spec = is the OAuth-only version of this already standard and deployed practice. = (There's other precedents for OAuth subsetting standard OpenID Connect func= tionality. For instance, RFC 8414 is = the OAuth-specific subset of the metadata format defined by OpenID Connect = Discovery.) -- Mike -----Original Message----- From: OAuth On Behalf Of Jim Schaad Sent: Wednesday, October 31, 2018 8:33 AM To: draft-ietf-oauth-jwsreq@ietf.org Cc: 'oauth' Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq As part of looking at the issues of using CWTs for this purpose I did some = more reading of the document. I am having a problem with the understanding= the reasons for using JWT as opposed to just saying that you are going to = use JWS and JWE. There is nothing in this section that I can see that poin= ts to a reason to be using JWTs as the carrier. What am I missing? Jim _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_MW2PR00MB0298547452BD260483C0CC50F5CD0MW2PR00MB0298namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JWT defines a number of standard claims that are = used in this application, including "iss" (issuer), "aud&quo= t; (audience), etc.  Making the requests a JWT allows code reuse, rath= er than having an application-specific signed request representation that has many of the semantics and fields of a JWT anyway.

 

It's also worth noting that this practice has bee= n a standard since 2014.  OpenID Connect Core standardized the OAuth s= igned request format in https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests.&n= bsp; The draft-ie= tf-oauth-jwsreq spec is the OAuth-only version of this already standard= and deployed practice.  (There's other precedents for OAuth subsettin= g standard OpenID Connect functionality.  For instance, RFC 8414= is the OAuth-specific subset of the metadata format defined by Open= ID Connect Discovery.)

 

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

 

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Jim Schaad
Sent: Wednesday, October 31, 2018 8:33 AM
To: draft-ietf-oauth-jwsreq@ietf.org
Cc: 'oauth' <oauth@ietf.org>
Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq

 

As part of looking at the issues of using CWTs fo= r this purpose I did some more reading of the document.  I am having a= problem with the understanding the reasons for using JWT as opposed to jus= t saying that you are going to use JWS and JWE.  There is nothing in this section that I can see that points= to a reason to be using JWTs as the carrier.  What am I missing?=

 

Jim

 

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/li= stinfo/oauth

--_000_MW2PR00MB0298547452BD260483C0CC50F5CD0MW2PR00MB0298namp_-- From nobody Wed Oct 31 15:12:37 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1169A130DDA for ; Wed, 31 Oct 2018 15:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=newcontext.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 c_-6IqZS4zXp for ; Wed, 31 Oct 2018 15:12:34 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 644EB130DD4 for ; Wed, 31 Oct 2018 15:12:34 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id bh10-v6so7939500plb.4 for ; Wed, 31 Oct 2018 15:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newcontext.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=kxfAPBlYQLaILwD8W9B1OeHRNHSjy0ctSTo9egcpU/s=; b=H1D3+7TFt1yETzygkIK7K3OGyhRrbSwPvjLNvckjMphFdzfl03X4CGSFpjGxcKEWy+ SvHMNhl8i9dy3OFXt/rWzbHoKbxgJs5PimqB37/PEe5lGEEcX1O93k7zT+ZjLJuEuqmR 5PIWNouFwzndMWfGiHdx9vv1V5M79hXlUXYwmFwQf7Di5lHDp2SftPHi7f7QXP501Udb 2tso472SleBTFfJE64b8Ds9TgylLf3vlobgQRwnOJo6hindjrut2cl/hRHLX+V7Bmfga ce7VofZlCmxL1o462JuR9HY+PMrQE1cO36exEouzBXxDuiduH5llFXrtSOyJJW3E7/eN 3MPQ== 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=kxfAPBlYQLaILwD8W9B1OeHRNHSjy0ctSTo9egcpU/s=; b=YgV6ySRR73pXx1TaZXrScfUus9kqycFvETIqzaTiQkFoG2bHYPUmjy0278AdfClYx4 7JX+Fq7Z9yDgr0R8f4KVo2GzUPNTnJMUUmxqoJ++jM57pDtuECR0rDOueYGMyl09uapc klxNZV0oH38voLhAj8geHRVDODUgYZSSXdkWdaus2isvBPNyJoZ5ywxS8GMKDqQfC74r 7Vj9ziHJp9YpWe6sJjji9HevCkVUWeCSM06sj+zRIX1LBMYIW5qFVkzXeZnBUwk1rwGA PgCBbhbbOSl1v/pV9yCfOiPFF0VcYQQv8lOxegh+Y3XEwwPVnI4eUgmRo4B4SyMzAPOJ R0/A== X-Gm-Message-State: AGRZ1gIb3cxQv7Jp2Ut/6Ci1g79frEvf9IlfDp/UdgA/Y8gl2v3sokxu nYd3v9zwkgwI0UQ+k7h2hwUGnevG7lk3vn1pNbHfEeX+o14= X-Google-Smtp-Source: AJdET5eb67C2UKeGMUc8wEt1c0KnA6BYBQ66XImndAwVyuWytmHV4oGLLvRHjiU7guWC2bazHugmZjzRoskvr22nQlQ= X-Received: by 2002:a17:902:2ec1:: with SMTP id r59-v6mr5063705plb.243.1541023953631; Wed, 31 Oct 2018 15:12:33 -0700 (PDT) MIME-Version: 1.0 From: John-Mark Gurney Date: Wed, 31 Oct 2018 15:12:22 -0700 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 22:12:36 -0000 I would suggest that the security considerations section of draft-ietf-oauth-mtls-12 be expanded to include the privacy implications of using this on versions of TLS before 1.3. On all versions of TLS before 1.3, the client cert is not encrypted and can be used by third parties to monitor and track users. I recently posted a blog entry about this: https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.html Thanks. John-Mark Gurney