From nobody Tue Sep 1 00:51:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0361B883A for ; Tue, 1 Sep 2015 00:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFu85bvjTX4R for ; Tue, 1 Sep 2015 00:51:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A723D1B883C for ; Tue, 1 Sep 2015 00:51:06 -0700 (PDT) Received: from [192.168.10.154] ([101.53.7.10]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Ljqgb-1YzXSA3OcD-00buzS for ; Tue, 01 Sep 2015 09:51:04 +0200 References: <20150901045617.CB44D187A98@rfc-editor.org> To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Forwarded-Message-Id: <20150901045617.CB44D187A98@rfc-editor.org> Message-ID: <55E544A6.3050203@gmx.net> Date: Tue, 1 Sep 2015 08:24:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150901045617.CB44D187A98@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3DiXM1rhQ9EveDxATvTTS7nnFMsTxBUj2" X-Provags-ID: V03:K0:bCVZXHL4RJJQ+osZKjOIir9aTahsFwAGgFzvP3X/5AKXPujK2yf riPQ3hkIbSLpKEzjde1Jp08+lsqTfZ9ZW2jxuuJy1G6A+h/vSn2oNDX5ET236BvzZVjLuAV Qs9PhB01ZrR+oxlCduMsa0jdOyq/NG9Uryc/b/x8f47Dm2vFIKbou0hRHi0/qtw3CBMRUDC AGvCWbKZ+KPIK8dVPKPvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:a+MKL4NuY2Y=:tZriwHFRJAhqw7vvcfULsU YaVvNeeq49YWCwMF0rYjOX8VebHFUsII+UkVLiCaogajXPERr+3Hq1I7edK0wu2jo9BUOUnEu 4kr27rHS/z6tUypYr4U9QjbBouc4/B9mYMYi1i3B1y/Ah2msgadGVOLxqsoxu8SzFAv4mvF0r 1cxcYuczTkXo3HYGKX/yxerZLpjVilQvia86lXBQ/qOyiJ2u85X4NhO9Cwsbtgn7Mddphs5s6 ZUfutGGZISrugs27oh3opgQXfg7VFD85BNpI4oG4cHfKjRa8eXStri1jjmuCeTQuAj89HUObN Qt9rWVgMoQ35k3WylGo5pyb9XT9DI6iYjqNBZbsGyV91G2LuAotmvaKOBS5GqJ6EhTggR5nUs uh9cpnIYWaeCa7NEb/9Z8efSL6OU7+0E0r+5zV4m38Gr/d3ZLYW4WadXU2/ZnWQ/tkbZWbE8f p6eKivjsWF5y9Dsoi2zXxj/W28QbDuBAVv1G5Y2Ksjf18Urb1rN8vh409X4IwtGXtYnspg6WB icPeHjjanrqQl8hO1GSRfaYZezF3G4AYu2bUkssh73bFoNi6GkI0aSiSyaSkMpEjZKas/LxJz yyszzH9FsUqZQ+y3FzqEEA3eMLJZP0+OnCcvfy9kX5QQY6IF4LFnB2KWVHPi8z0MxoYCuIL3U fagB1Io2tiFEPuuY3vvC91onn6Fa1N9dglX2HSk039YArLppZOEWQ49OhBkSq481ES0Mu253V cc6LJkchNv271JyAae+DO3CTLC0IVYAVHqQ4cw== Archived-At: Subject: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 07:51:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3DiXM1rhQ9EveDxATvTTS7nnFMsTxBUj2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI: Thanks to Bill for the hard work! -------- Forwarded Message -------- Subject: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: kitten@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.or= g A new Request for Comments is now available in online RFC libraries. RFC 7628 Title: A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth Author: W. Mills, T. Showalter, H. Tschofenig Status: Standards Track Stream: IETF Date: August 2015 Mailbox: wmills_92105@yahoo.com, tjs@psaux.com, Hannes.Tschofenig@gmx.net Pages: 21 Characters: 46408 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt URL: https://www.rfc-editor.org/info/rfc7628 DOI: http://dx.doi.org/10.17487/RFC7628 OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggesti= ons for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for th= e standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --3DiXM1rhQ9EveDxATvTTS7nnFMsTxBUj2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV5USnAAoJEGhJURNOOiAt9XUH/RuNw7w0TVnTgHsg/JIVVXZG SOho4/98YCzWkvpWkgV8VShc+qm+gW7jtiru0wUoaoxZwweydBvKtuvGn5evO63x puHfQNbAlKfVpj0g9ERpYDZNYU8RkkJ7X+ncn9dAOA8TsLtYYPcraypf3/50ubSM S+C2FaVoefHLOFaODUI9Qkn+kfneUHEEnSNR14sPF08SGZ8LAP0l0BfC6ZGB/Xqo gAhJeQphd/ZpBjLQ641OeuYpFq97schmqx+7ucLMjqd2hW7uRXY8gfR1Oe13YA3r hmpWMff6s8GnMz5sZbyJE2ia60NSOcpamdiqp1i8h8afEwabnno/9eT8PrQYPgI= =ryqR -----END PGP SIGNATURE----- --3DiXM1rhQ9EveDxATvTTS7nnFMsTxBUj2-- From nobody Tue Sep 1 03:08:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC9B1B5ABA for ; Tue, 1 Sep 2015 03:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.609 X-Spam-Level: ** X-Spam-Status: No, score=2.609 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTYR1JTS2S7F for ; Tue, 1 Sep 2015 03:08:06 -0700 (PDT) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66A41B7C5C for ; Tue, 1 Sep 2015 03:07:07 -0700 (PDT) Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs02.index.or.jp (Postfix) with SMTP id 3957E19688A; Tue, 1 Sep 2015 19:07:06 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id t81A757p000388; Tue, 1 Sep 2015 19:07:06 +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 t81A75W1016184; Tue, 1 Sep 2015 19:07:05 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id t81A75PE016183; Tue, 1 Sep 2015 19:07:05 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t81A753d016180; Tue, 1 Sep 2015 19:07:05 +0900 From: "Nat Sakimura" To: "'John Bradley'" , "'Donghwan Kim'" References: In-Reply-To: Date: Tue, 1 Sep 2015 19:07:06 +0900 Message-ID: <03a001d0e49d$f4d5b8f0$de812ad0$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A1_01D0E4E9.64BFAAE0" X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20150401 Thread-Index: AQJDtk7dG+Ls5gtA16bKkfXo7cQ3ZwMtHEfJnShmERA= Content-Language: ja Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Lifetime of refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 10:08:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03A1_01D0E4E9.64BFAAE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Right. I wrote =E2=80=9Cpseudo-authentication=E2=80=9D because it does = not qualify as authentication.=20 In another word, I am saying =E2=80=9CDO NOT DO IT.=E2=80=9D =20 --=20 Nat Sakimura < n-sakimura@nri.co.jp> Nomura Research Institute, Ltd.=20 =20 PLEASE READ: The information contained in this e-mail is confidential and intended = for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system. =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, August 25, 2015 12:08 AM To: Donghwan Kim Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Lifetime of refresh token =20 I think Nat=E2=80=99s diagram about the problems of doing pseudo = authentication with OAuth is being taken out of context. =20 The refresh token dosen=E2=80=99t expire, it is revoked by the user or = system. In some cases refresh tokens are automatically revoked if the = users session to the AS ends. I think AOL typically revokes refresh = tokens when sessions terminate. =20 OpenID Connect provides a separate id_token with a independent lifetime = from the refresh token. A client may keep a refresh token for a much = longer time than the user has a login session with the AS. =20 Refresh tokens are typically used by confidential clients that are using = a client secret in combination with the refresh token for getting a new = access token. =20 By design access tokens should be short lived as the AS is expected to = have a way of revoking refresh tokens but not access tokens. A access token that dosen't expire , and can=E2=80=99t be revoked is not = a good idea. =20 John B. =20 =20 On Aug 24, 2015, at 2:41 AM, Donghwan Kim > wrote: =20 Hi, =20 According to Figure 2 from = http://tools.ietf.org/html/rfc6749#section-1.5, refresh token can be = used to refresh an expired access token without requesting resource = owner to sign in again (uncomfortable experience). However, if it's = true, isn't it that refresh token might be used to request a new access = token even years later? and then isn't refresh token the same with = access token which never expires? =20 I intended to use refresh token to implement persistent login by sending = a refresh request before issued access token expires (expires_in runs = out). But if refresh token works even if access token expired already, = sending a refresh request on application start up would be enough. =20 So I'm not sure what I'm missing about refresh token as well as how to = implement persistent login using it (you can regard authentication here = pseudo-authentication illustrated in = https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-Authe= nticationusingOAuth.svg). What is the lifetime of refresh token? =20 Thanks, =20 -- Donghwan _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_03A1_01D0E4E9.64BFAAE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

R= ight. I wrote =E2=80=9Cpseudo-authentication=E2=80=9D because it does = not qualify as authentication.

I= n another word, I am saying =E2=80=9CDO NOT DO = IT.=E2=80=9D

<= o:p> 

-- =

Nat Sakimura = <n-sakimura@nri.co.jp= >

Nomura Research = Institute, Ltd.

 

PLEASE = READ:

The information = contained in this e-mail is confidential and intended for the named = recipient(s) only.

If you are not an = intended recipient of this e-mail, you are hereby notified that any = review, dissemination, distribution or duplication of this message is = strictly prohibited. If you have received this message in error, please = notify the sender immediately and delete your copy from your = system.

<= o:p> 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Tuesday, August 25, 2015 12:08 AM
To: = Donghwan Kim <flowersinthesand@gmail.com>
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] Lifetime of refresh = token

 

I think Nat=E2=80=99s diagram about the problems of doing = pseudo authentication with OAuth is being taken out of = context.

 

The refresh token dosen=E2=80=99t = expire, it is revoked by the user or system.  In some cases refresh = tokens are automatically revoked if the users session to the AS ends. =  I think AOL typically revokes refresh tokens when sessions = terminate.

 

OpenID Connect provides a separate = id_token with a independent lifetime from the refresh token.  A = client may keep a refresh token for a much longer time than the user has = a login session with the AS.

 

Refresh tokens are typically used = by confidential clients that are using a client secret in combination = with the refresh token for getting a new access = token.

 

By design access tokens should be = short lived as the AS is expected to have a way of revoking refresh = tokens but not access tokens.

A access token that dosen't expire = , and can=E2=80=99t be revoked is not a good = idea.

 

John = B.

 

 

On Aug 24, 2015, at 2:41 AM, = Donghwan Kim <flowersinthesand@gmail.com= > wrote:

 

Hi,

 

According to Figure 2 from http://tools.ietf= .org/html/rfc6749#section-1.5, refresh token can be used to refresh = an expired access token without requesting resource owner to sign in = again (uncomfortable experience). However, if it's true, isn't it that = refresh token might be used to request a new access token even years = later? and then isn't refresh token the same with access token which = never expires?

 

I intended to use refresh token to = implement persistent login by sending a refresh request before issued = access token expires (expires_in runs out). But if refresh token works = even if access token expired already, sending a refresh request on = application start up would be enough.

 

So I'm not sure what I'm missing = about refresh token as well as how to implement persistent login using = it (you can regard authentication here pseudo-authentication illustrated = in https://upload.wikimedia.org/wikipedia/c= ommons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg). What is = the lifetime of refresh token?

 

Thanks,

 

-- = Donghwan

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

 

------=_NextPart_000_03A1_01D0E4E9.64BFAAE0-- From nobody Tue Sep 1 03:10:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C871B7A39 for ; Tue, 1 Sep 2015 03:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAi4w6nkSJdA for ; Tue, 1 Sep 2015 03:10:29 -0700 (PDT) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BEA1B7813 for ; Tue, 1 Sep 2015 03:10:28 -0700 (PDT) Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs03.index.or.jp (Postfix) with SMTP id 7385517EA6D; Tue, 1 Sep 2015 19:10:28 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp (unknown) with ESMTP id t81AARxI028313; Tue, 1 Sep 2015 19:10:28 +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 t81AARtm022886; Tue, 1 Sep 2015 19:10:27 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id t81AARwS022885; Tue, 1 Sep 2015 19:10:27 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t81AARpA022881; Tue, 1 Sep 2015 19:10:27 +0900 From: "Nat Sakimura" To: "'Mike Jones'" , "'Nat Sakimura'" References: In-Reply-To: Date: Tue, 1 Sep 2015 19:10:28 +0900 Message-ID: <03a501d0e49e$6d651090$482f31b0$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A6_01D0E4E9.DD565580" X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20150401 Thread-Index: AQI8rw88xVrSUZf2Azu7U+G6OlE3uZ1P3FCw Content-Language: ja Archived-At: Cc: 'oauth' Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 10:10:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03A6_01D0E4E9.DD565580 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks very much! =20 It looks good except that bit more text can be put into Privacy = Consideration by looking at RFC6973, but it is not a blocking thing.=20 =20 Best,=20 =20 --=20 Nat Sakimura < n-sakimura@nri.co.jp> Nomura Research Institute, Ltd.=20 =20 PLEASE READ: The information contained in this e-mail is confidential and intended = for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system. =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Saturday, August 29, 2015 10:03 AM To: Nat Sakimura Cc: oauth Subject: Re: [OAUTH-WG] Review Comments for = draft-ietf-oauth-proof-of-possession-02 =20 Thanks again for your detailed review, Nat. The remainder of the issues = you raised are addressed in the -04 draft = . = Replies are inline prefixed by Mike> =E2=80=A6 =20 From: Nat Sakimura [mailto:sakimura@gmail.com]=20 Sent: Tuesday, August 18, 2015 9:00 PM To: Mike Jones Cc: oauth Subject: Re: [OAUTH-WG] Review Comments for = draft-ietf-oauth-proof-of-possession-02 =20 Inline:=20 =20 2015-08-11 14:12 GMT+09:00 Mike Jones >: Replies inline=E2=80=A6 =20 From: OAuth [mailto: = oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, March 25, 2015 6:38 AM To: oauth Subject: [OAUTH-WG] Review Comments for = draft-ietf-oauth-proof-of-possession-02 =20 Dear OAuthers:=20 =20 Here is my belated review comments on = draft-ietf-oauth-proof-of-possession-02 =20 Below, [POPA] stands for = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 = =20 =20 Abstract =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It is probably better to spell out that this document is describing the = JWT format that can be used for sender constraint (5.2 of [POPA]) and = key confirmation (5.3 of [POPA]). This will make it easier for the = reader to understand what this document aims at.=20 =20 It does not seem to me that the =E2=80=9CSender Constraint=E2=80=9D = concept described in 5.3 of [POPA] is the same =20 5.2 I guess, not 5.3.=20 =20 thing as identifying a proof-of-possession key within a JWT, which is = the purpose of this specification. In this specification, the issuer = makes a statement that the presenter can confirm possession of a key. I = don=E2=80=99t know how that would map into a =E2=80=9CSender = Constraint=E2=80=9D. For one thing, which party are you considering to = be the =E2=80=9CSender=E2=80=9D? Accordingly, I left the abstract = unchanged. =20 OK. Since the draft was titled "Proof of Possession Semantics for for = JSON Web Tokens (JWTs)", I pointed it out that it should not only talk = about 5.3 of [POPA] but also 5.2. However, now that you have changed the = tile to "Proof of Possession KEY Semantics for for JSON Web Tokens = (JWTs)", this issue is resolved. It would be nice to state that it is = talking about 5.3 of [POPA] in the introduction though.=20 =20 Mike> I have added this to the introduction in response to your comment: =E2=80=9CSee for a = further discussion of key confirmation.=E2=80=9D =20 Accordingly, we should consider the title change to something like:=20 JWT Sender Confirmation Token Syntax=20 OR borrowing from the financial concept which I believe is the origin of = the concept of "bearer token",=20 JWT Registered Token Syntax -- here, "Registered" mean that either the sender constraint or key = confirmation is registered within or in conjunction with the token.=20 =20 I changed the title in -03 to =E2=80=9CProof-of-Possession Key Semantics = for JSON Web Tokens (JWTs)=E2=80=9D to make it clear this draft is about = PoP key semantics for JWTs =E2=80=93 not the proof-of-possession = mechanism itself. I=E2=80=99ve already responded to the =E2=80=9CSender = Constraint=E2=80=9D suggestion above. Per my earlier response, I = don=E2=80=99t believe that =E2=80=9CRegistered Token=E2=80=9D is = standard terminology, and so would confuse more than it would clarify. =20 Now that you have clarified that this document is only about 5.3 of = [POPA],=20 the title in -03 is appropriate.=20 =20 NOTE: "Registered *" is a very well established term in financial = industry,=20 describing kind of "token" needed to be presented to exercise the right = assigned to it. =20 e.g., Registered Security, Registered Share Certificate, etc.=20 =20 =20 1. Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Consider referencing draft-ietf-oauth-pop-architecture.=20 It will be clearer for the reader then, and the text will be shorter.=20 =20 Again, I suspect you=E2=80=99re asking me to reference this draft for = the =E2=80=9CSender Constraint=E2=80=9D terminology, which is both = vaguely defined in [POPA], and doesn=E2=80=99t match what this = specification does. Therefore, I did not do this here, although other = appropriate references to [POPA] are included. =20 It would be nice to point out that this document is talking about the = model presented in 5.3 of [POPA]. =20 My suggestion: Insert ", as described in section 5.3 of [POPA]" before = the end of the Para 1.=20 =20 This specification defines how to express a declaration in a JSON Web Token (JWT) [JWT] that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key,=20 as described in section 5.3 of [POPA].=20 =20 Mike> As noted earlier, I have added this to the introduction in = response to your comment: =E2=80=9CSee for a = further discussion of key confirmation.=E2=80=9D I did not reference a specific section number because = ietf-oauth-pop-architecture has not yet entered the RFC Editor queue, = and so the section number may change. =20 =20 2. Terminology - Presenter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sentence 1 ------------------- Not sure if the first sentence is accurately reflecting the intent.=20 It excludes rogue party presenting the token (and fails) from presenter. = If so, it is fine but using more qualified term like "authorized = presenter" may make it easier=20 for the reader to parse.=20 =20 Otherwise revise the definition.=20 =20 I believe the =E2=80=9CPresenter=E2=80=9D definition accurately matches = its usage in this specification. While this is related to a different = discussion, I=E2=80=99m not aware of a definition for = =E2=80=9CAuthorized Presenter=E2=80=9D that could be referenced that = would add further clarity beyond the existing definition. (Note that = the OpenID Connect =E2=80=9Cazp=E2=80=9D claim is for an = =E2=80=9CAuthorized Party=E2=80=9D to which the token was issued = =E2=80=93 not an =E2=80=9CAuthorized Presenter=E2=80=9D. Also, note = that the usage of =E2=80=9Cazp=E2=80=9D in = http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-04 = is inconsistent with its definition in OpenID Connect, and so should = probably be revised to use the =E2=80=9CAuthorized Party=E2=80=9D = terminology or removed, as it does not identify an =E2=80=9CAuthorized = Presenter=E2=80=9D in the way that I think you are using the term.) =20 =20 It is not a good practice to define such a generic word like = "presenter".=20 Since you have used "presenter" as party that holds the key,=20 we have lost the word for the rogue party that presents the token=20 without the key.=20 =20 Mike> =E2=80=9CPresenter=E2=80=9D is no more generic than = =E2=80=9CIssuer=E2=80=9D or =E2=80=9CRecipient=E2=80=9D. All are = standard terms for these kinds of flows, so I=E2=80=99m reluctant to = invent new terminology. By design and by definition, a rogue party who = does not hold the key is not a presenter. (In the same way, a party who = creates a JWT and signs a forged =E2=80=9Ciss=E2=80=9D value with a key = other the named issuer=E2=80=99s keys is not the issuer.) The standard = term for such a party is =E2=80=9Cthe attacker=E2=80=9D; we = haven=E2=80=99t lost the word for such a party. =20 Also, the current definition includes the issuer in the presenter.=20 Issuer is not typically a party that is supposed to present the token to = the resource,=20 so the term seems to be especially weird.=20 =20 Sentence 2 ------------------- "issuer or a party different from the issuer" is not constraining = anything and meaningless.=20 There are more easier to parse and accurate text coming in the main = text, too.=20 Drop.=20 =20 The phrase expresses the intentional *lack of constraint*, by stating = that the presenter might be the issuer or might be a party different = from the issuer. Too many times in the past people thought the two were = the same party (and indeed, this error occurred in several places in = -02), therefore, I believe that expressing this non-constraint adds = value. If you want to suggest alternative wording to express this = non-constraint, I=E2=80=99d be glad to consider it. =20 What is the most usual case? Is presenter usually the issuer?=20 I do not think so.=20 So, if we really want to express the lack of constraint, then something = like this would be better:=20 =20 The presenter is usually distinct from the issuer, but the issuer can be = a presenter as well.=20 =20 Also, I have to point out that the characteristics of this sentence is = more like a note to definition and not the definition itself.=20 =20 Mike> I=E2=80=99ve deleted this sentence from the draft =E2=80=9CThe = presenter may be the issuer or a party distinct from the = issuer.=E2=80=9D It seems to have been causing more confusion than = clarity. =20 =20 3. Proof-Of-Possession Representation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Title --------- Perhaps "Sender Representation in JWT" is more reflective of the = content.=20 =20 This was changed to =E2=80=9CRepresentations for Proof-of-Possession = Keys=E2=80=9D in -03 to clarifying that it is the PoP key being = represented, not the proof-of-possession itself. =20 OK.=20 =20 =20 Para 2 ------------- The paragraph describes two ways of sender confirmation:=20 (1) Sender Constraint (2) Key Confirmation It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the = terminology.=20 =20 As described above, the =E2=80=9CSender Constraint=E2=80=9D terminology = in [POPA] does not match what this specification does. =20 The title change clarified the situation so now it is ok.=20 =20 =20 Then, it goes on to describe (1) very briefly, in which it is just = spelling out "iss" and "sub".=20 =20 I understand the use of sub in this section comes down from SAML but I = feel that some separation between sub and presenter would be nice.=20 For example, when I am presenting the token using an app that I = installed on my iPhone, the presenter is that app and not me, while the = sub still may be me. The app is the authorized presenter/party (azp) of = the token. The JWT may well be about the sub but presented by some = software component that should be independently identified. =20 So my proposal is to create a new subsection on (1) for the = completeness, which is going to be a new 3.1, and to use a claim like = "azp" instead of "sub" to identify the presenter. Less overload would = cause less confusion later, IMHO. =20 Per your request, = = https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03#secti= on-3 was revised to include a description of the use of the = =E2=80=9Cazp=E2=80=9D claim as a choice that applications can employ to = identify the presenter, if appropriate. =20 Thank you.=20 =20 =20 3.1 =3D=3D=3D=3D=3D=3D Title -------- Perhaps "Confirmation Key Representation for an Asymmetric Key" is more = reflective of the content.=20 =20 This was changed to =E2=80=9CRepresentation for an Asymmetric = Proof-of-Possession Key=E2=80=9D. =20 Thanks.=20 =20 =20 3.2 =3D=3D=3D=3D=3D=3D=3D=3D Title ----------- Perhaps "Confirmation Key Representation for a Symmetric Key" is more = reflective of the content.=20 =20 This was changed to =E2=80=9CRepresentation for an Encrypted Symmetric = Proof-of-Possession Key=E2=80=9D. =20 Thanks.=20 =20 =20 Last Para ----------------- I feel a bit like needing to sniff into the content of jwk to find out = what type may not be optimal, though I do not have a concrete proposal a = this time.=20 =20 The =E2=80=9Cjwe=E2=80=9D member was introduced in -03 to eliminate the = need for this sniffing. =20 Thanks.=20 =20 =20 3.3 =3D=3D=3D=3D=3D=3D Title --------- Perhaps "Confirmation Key Representation by Key ID" is more reflective = of the content.=20 =20 This was changed to =E2=80=9CRepresentation of a Key ID for a = Proof-of-Possession Key=E2=80=9D. =20 Thanks.=20 =20 =20 Para 1 ----------- There has been some discussion of using thumbprint instead of a blob = "kid".=20 This is a valid option. If we are to overload the "kid" member for this = purpose, we need to find a way to signal that it is a thumbprint.=20 It may very well be better to define a separate member name then for the = thumbprint. The title then changes to "-- by Key ID" to "-- by = reference".=20 =20 For the same reasons that the =E2=80=9Cjkt=E2=80=9D definition was = removed from draft-ietf-jose-jwk-thumbprint, it=E2=80=99s not clear that = it=E2=80=99s needed here. Applications are free to define that the = =E2=80=9Ckid=E2=80=9D is to contain a key thumbprint using a particular = hash function. =20 OK. So you mean that it should be specified in the application layer. = That is acceptable, but then mentioning it in the text would be nice.=20 =20 Mike> Fair point. I=E2=80=99ve added this text to address your = suggestion: =E2=80=9CThe content of the kid value is application specific. For instance, some applications may choose to use a = JWK Thumbprint value as the kid = value.=E2=80=9D =20 Also, it is conceivable to use the combination of "kid" and "jku". This = aspect is not spelled out here but appears that some magic happens for = the key distribution.=20 =20 You=E2=80=99re right that if =E2=80=9Ckid=E2=80=9D is used, unless the = key is also transmitted in the =E2=80=9Ccnf=E2=80=9D claim, distribution = of the key is out of scope of the specification. I can imagine methods = using =E2=80=9Cjku=E2=80=9D but it seems like we should discuss this = more before normatively specifying it at this time. =20 Looking forward to.=20 =20 Mike> The more I thought about this, the more I agreed that = =E2=80=9Cjku=E2=80=9D was needed to enable PoP keys to be passed by = reference. Please review the text adding =E2=80=9Cjku=E2=80=9D at = http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04#sectio= n-3.5. =20 =20 3.4=20 =3D=3D=3D=3D=3D=3D=3D=3D Since "cnf" appears before 3.4, it may be better to bring 3.4 at the = front.=20 =20 Agreed. Sorry I missed doing this in -03. I=E2=80=99ll plan to do this = in -04. =20 Looking forward to.=20 Note that this is not an endorsement for structured cnf, but rather,=20 it was just an editorial point that I raised.=20 =20 Mike> Done. The former 3.4 is now 3.1. =20 5.2.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D Add "azp" and "jkt".=20 =20 o Confirmation Method Value: "azp" o Confirmation Method Description: Client ID of the Authorized = Presenter o Change Controller: IESG o Specification Document(s): Section [TBD] of [[ this document ]] Having a Client ID doesn=E2=80=99t identify a proof-of-possession key, = so this request seems to be out of place relative to the purpose of this = specification. =20 Indeed. If the title was like before the change, it would have been, but = now the title and the scope is smaller, it is out of scope, I think..=20 =20 o Confirmation Method Value: "jkt" o Confirmation Method Description: JWK Thumbprint of the Confirmation = Key o Change Controller: IESG o Specification Document(s): Section [TBD] of [[ this document ]] As discussed earlier, =E2=80=9Ckid=E2=80=9D can already be used to hold = a key thumbprint value. =20 OK. =20 o Confirmation Method Value: "jku" o Confirmation Method Description: JWK URI of the Confirmation Key o Change Controller: IESG o Specification Document(s): Section [TBD] of [[ this document ]] =20 We should have a discussion focused specifically on this proposed = addition. I can see the value of it, but would like to get input from = more working group members. What do people think? (If this discussion = doesn=E2=80=99t happen based on this response, we should probably start = a separate thread on this topic.) =20 OK.=20 =20 Mike> Done =E2=80=93 thanks! =20 Privacy Consideration =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It is missing privacy consideration. It is not required per se, but = since Key Confirmation method with ephemeral key can be less privacy = intrusive compared to other sender confirmation method so adding some = text around it may be a good idea.=20 =20 Can you supply some specific proposed text for -04? =20 When do you expect -04?=20 Depending on it, I may be able to.=20 =20 Mike> I wrote a Privacy Considerations section, addressing the use of = confirmation keys as correlation handles. =20 =20 Best,=20 --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ = =20 @_nat_en =20 Thanks again for your useful review comments! =20 -- Mike =20 =20 --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ = =20 @_nat_en =20 Thanks = again, Nat! -- Mike =20 ------=_NextPart_000_03A6_01D0E4E9.DD565580 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

T= hanks very much!

<= o:p> 

I= t looks good except that bit more text can be put into Privacy = Consideration by looking at RFC6973, but it is not a blocking thing. =

<= o:p> 

B= est,

<= o:p> 

-- =

Nat Sakimura = <n-sakimura@nri.co.jp= >

Nomura Research = Institute, Ltd.

 

PLEASE = READ:

The information = contained in this e-mail is confidential and intended for the named = recipient(s) only.

If you are not an = intended recipient of this e-mail, you are hereby notified that any = review, dissemination, distribution or duplication of this message is = strictly prohibited. If you have received this message in error, please = notify the sender immediately and delete your copy from your = system.

<= o:p> 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Saturday, August 29, 2015 10:03 AM
To: = Nat Sakimura <sakimura@gmail.com>
Cc: oauth = <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Review Comments = for = draft-ietf-oauth-proof-of-possession-02

=

 

Thanks again for your detailed review, Nat.  The remainder of the = issues you raised are addressed in the -04 draft.  Replies are inline prefixed by Mike> = =E2=80=A6

 

From: Nat Sakimura = [mailto:sakimura@gmail.com] =
Sent: Tuesday, August 18, 2015 9:00 PM
To: Mike = Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Review = Comments for = draft-ietf-oauth-proof-of-possession-02

 

Inline: 

 

2015-08-11 14:12 GMT+09:00 Mike = Jones <Michael.Jones@microsoft.com>:<= /p>

Replies inline=E2=80=A6

 

From: OAuth = [mailto:oauth-bounces@= ietf.org] On = Behalf Of Nat Sakimura
Sent: Wednesday, March 25, 2015 = 6:38 AM
To: oauth
Subject: [OAUTH-WG] Review = Comments for draft-ietf-oauth-proof-of-possession-02

 

Dear OAuthers: 

 

Here is my belated review comments on draft-ietf-oauth-proof-of-possession-02

 

 

Abstract

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

It is probably better to spell out that this document is = describing the JWT format that can be used for sender constraint (5.2 of = [POPA]) and key confirmation (5.3 of [POPA]). This will make it easier = for the reader to understand what this document aims = at. 

 

It does not seem to me that the =E2=80=9CSender Constraint=E2=80=9D = concept described in 5.3 of [POPA] is the same

 

5.2 I guess, not = 5.3. 

 

thing as identifying a proof-of-possession key within a JWT, which is = the purpose of this specification.  In this specification, the = issuer makes a statement that the presenter can confirm possession of a = key.  I don=E2=80=99t know how that would map into a = =E2=80=9CSender Constraint=E2=80=9D.  For one thing, which party = are you considering to be the =E2=80=9CSender=E2=80=9D?  = Accordingly, I left the abstract unchanged.

<= div>

 

OK. Since the draft was titled = "Proof of Possession Semantics for for JSON Web Tokens (JWTs)", I pointed it out = that it should not only talk about 5.3 of [POPA] but also 5.2. However, = now that you have changed the tile to "Proof of = Possession KEY Semantics for for JSON Web Tokens (JWTs)", this issue is = resolved. It would be nice to state that it is talking about 5.3 of = [POPA] in the introduction = though. 

 

Mike> I have added this to the introduction in response to your = comment:

=E2=80=9CSee <xref = target=3D"I-D.ietf-oauth-pop-architecture"/> for a further = discussion of key = confirmation.=E2=80=9D

 

Accordingly, we should consider the title change to = something like: 

JWT Sender Confirmation Token = Syntax 

  OR

borrowing from the financial concept which I believe is the = origin of the concept of "bearer = token", 

JWT Registered Token = Syntax

-- here, "Registered" mean that either the sender = constraint or key confirmation is registered within or in conjunction = with the token. 

 

I changed the title in -03 to =E2=80=9CProof-of-Possession Key = Semantics for JSON Web Tokens (JWTs)=E2=80=9D to make it clear this = draft is about PoP key semantics for JWTs =E2=80=93 not the = proof-of-possession mechanism itself.  I=E2=80=99ve already = responded to the =E2=80=9CSender Constraint=E2=80=9D suggestion = above.  Per my earlier response, I don=E2=80=99t believe that = =E2=80=9CRegistered Token=E2=80=9D is standard terminology, and so would = confuse more than it would clarify.

 

Now that you have clarified that = this document is only about 5.3 of = [POPA], 

the title in -03 is = appropriate. 

 

NOTE: "Registered *" is a = very well established term in financial = industry, 

describing kind of = "token" needed to be presented to exercise the right assigned = to it.  

e.g., Registered Security, Registered Share Certificate, = etc. 

 

 

1. Introduction

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Consider referencing = draft-ietf-oauth-pop-architecture. 

=

It will be clearer for the reader then, and the text will = be shorter. 

 

Again, I suspect you=E2=80=99re asking me to reference this draft for = the =E2=80=9CSender Constraint=E2=80=9D terminology, which is both = vaguely defined in [POPA], and doesn=E2=80=99t match what this = specification does.  Therefore, I did not do this here, although = other appropriate references to [POPA] are included.

 

It would be nice to point out that = this document is talking about the model presented in 5.3 of [POPA]. =  

My suggestion: Insert ", as described in section 5.3 of = [POPA]" before the end of the Para = 1. 

 

   This specification =
defines how to express a declaration in a JSON =
Web
   Token (JWT) [JWT] that the presenter =
of the JWT possesses a
   particular key and that the recipient =
can cryptographically confirm
   proof-of-possession of =
the key by the presenter.  This property =
is
   also sometimes described as the =
presenter being a holder-of-key, 
   as described =
in section 5.3 of [POPA]. 
 

Mike> As noted earlier, I have added this to the introduction in = response to your comment:

=E2=80=9CSee <xref = target=3D"I-D.ietf-oauth-pop-architecture"/> for a further = discussion of key confirmation.=E2=80=9D

I did not reference a specific section number because = ietf-oauth-pop-architecture has not yet entered the RFC Editor queue, = and so the section number may change.

 

 

2. Terminology - = Presenter

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Sentence 1

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

Not sure if the first sentence is accurately reflecting the = intent. 

It excludes rogue party presenting the token (and fails) = from presenter. 

If so, it is fine but using more qualified term like = "authorized presenter" may make it = easier 

for the reader to = parse. 

 

Otherwise revise the = definition. 

 

I believe the =E2=80=9CPresenter=E2=80=9D definition accurately matches = its usage in this specification.  While this is related to a = different discussion, I=E2=80=99m not aware of a definition for = =E2=80=9CAuthorized Presenter=E2=80=9D that could be referenced that = would add further clarity beyond the existing definition.  (Note = that the OpenID Connect =E2=80=9Cazp=E2=80=9D claim is for an = =E2=80=9CAuthorized Party=E2=80=9D to which the token was issued = =E2=80=93 not an =E2=80=9CAuthorized Presenter=E2=80=9D.  Also, = note that the usage of =E2=80=9Cazp=E2=80=9D in http://tools.= ietf.org/html/draft-sakimura-oauth-rjwtprof-04 is inconsistent with its definition in OpenID Connect, and so should = probably be revised to use the =E2=80=9CAuthorized Party=E2=80=9D = terminology or removed, as it does not identify an =E2=80=9CAuthorized = Presenter=E2=80=9D in the way that I think you are using the = term.)

 

 

It is not a good practice to define = such a generic word like = "presenter". 

Since you have used = "presenter" as party that holds the = key, 

we have lost the word for the rogue party that presents the = token 

without the key. 

 

Mike> =E2=80=9CPresenter=E2=80=9D is no more generic than = =E2=80=9CIssuer=E2=80=9D or =E2=80=9CRecipient=E2=80=9D.  All are = standard terms for these kinds of flows, so I=E2=80=99m reluctant to = invent new terminology.  By design and by definition, a rogue party = who does not hold the key is not a presenter.  (In the same way, a = party who creates a JWT and signs a forged =E2=80=9Ciss=E2=80=9D value = with a key other the named issuer=E2=80=99s keys is not the = issuer.)  The standard term for such a party is =E2=80=9Cthe = attacker=E2=80=9D; we haven=E2=80=99t lost the word for such a = party.

 

Also, the current definition includes the issuer in the = presenter. 

Issuer is not typically a party = that is supposed to present the token to the = resource, 

so the term seems to be especially = weird. 

 

Sentence 2

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

"issuer or a party different from the issuer" is = not constraining anything and = meaningless. 

There are more easier to parse and accurate text coming in = the main text, too. 

Drop. 

 

The phrase expresses the intentional *lack of constraint*, by = stating that the presenter might be the issuer or might be a party = different from the issuer.  Too many times in the past people = thought the two were the same party (and indeed, this error occurred in = several places in -02), therefore, I believe that expressing this = non-constraint adds value.  If you want to suggest alternative = wording to express this non-constraint, I=E2=80=99d be glad to consider = it.

 

What is the most usual case? Is = presenter usually the issuer? 

I do not think = so. 

So, if we really want to express the lack of constraint, = then something like this would be = better: 

 

The presenter is usually distinct = from the issuer, but the issuer can be a presenter as = well. 

 

Also, I have to point out that the = characteristics of this sentence is more like a note to definition and = not the definition itself. 

 

Mike> I=E2=80=99ve deleted this sentence from the draft =E2=80=9CThe = presenter may be the issuer or a party distinct from the = issuer.=E2=80=9D  It seems to have been causing more confusion than = clarity.

 

 

3. Proof-Of-Possession = Representation

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Title

---------

Perhaps "Sender Representation in JWT" is more = reflective of the content. 

 

This was changed to =E2=80=9CRepresentations for Proof-of-Possession = Keys=E2=80=9D in -03 to clarifying that it is the PoP key being = represented, not the proof-of-possession itself.

 

OK. 

 

 

Para 2

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

The paragraph describes two ways of sender = confirmation: 

(1) Sender Constraint

(2) Key Confirmation

It should refer to 5.2 and 5.3 of [POPA] for it, as well as = align the terminology. 

 

As described above, the =E2=80=9CSender Constraint=E2=80=9D terminology = in [POPA] does not match what this specification does.

 

The title change clarified the = situation so now it is ok. 

 

 

Then, it goes on to describe (1) very briefly, in which it = is just spelling out "iss" and = "sub". 

 

I understand the use of sub in this section comes down from = SAML but I feel that some separation between sub and presenter would be = nice.

For example, when I am presenting the token using an app = that I installed on my iPhone, the presenter is that app and not me, = while the sub still may be me. The app is the authorized presenter/party = (azp) of the token. The JWT may well be about the sub but presented = by some software component that should be independently identified. =  


So my proposal is to create a new subsection on (1) for = the completeness, which is going to be a new 3.1, and to use a claim = like "azp" instead of "sub" to identify the = presenter. Less overload would cause less confusion later, = IMHO.

 

3.4 

=3D=3D=3D=3D=3D=3D=3D=3D

Since "cnf" appears before 3.4, it may be better = to bring 3.4 at the = front. 

 

Agreed.  Sorry I missed doing this in -03.  I=E2=80=99ll plan = to do this in -04.

 

Looking forward = to. 

Note that this is not an endorsement for structured cnf, = but rather, 

it was just an editorial point that = I raised. 

 

Mike> Done.  The former 3.4 is now = 3.1.

 

5.2.2

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

Add "azp" and = "jkt". 

 

o  Confirmation Method Value: "azp"
o =  Confirmation Method Description: Client ID of the Authorized = Presenter
o  Change Controller: IESG
o  Specification = Document(s): Section [TBD] of [[ this document = ]]

Having a Client ID doesn=E2=80=99t = identify a proof-of-possession key, so this request seems to be out of = place relative to the purpose of this specification.

<= div>

 

Indeed. If the title was like = before the change, it would have been, but now the title and the scope = is smaller, it is out of scope, I = think.. 

 



o  Confirmation Method Value: = "jkt"
o  Confirmation Method Description: JWK = Thumbprint of the Confirmation Key
o  Change Controller: = IESG
o  Specification Document(s): Section [TBD] of [[ this = document ]]

As discussed earlier, = =E2=80=9Ckid=E2=80=9D can already be used to hold a key thumbprint = value.

<= div>

 

OK. =  



o  Confirmation Method Value: = "jku"
o  Confirmation Method Description: JWK URI of = the Confirmation Key
o  Change Controller: IESG
o =  Specification Document(s): Section [TBD] of [[ this document = ]]

 

We should have a discussion focused specifically on this proposed = addition.  I can see the value of it, but would like to get input = from more working group members.  What do people think?  (If = this discussion doesn=E2=80=99t happen based on this response, we should = probably start a separate thread on this topic.)

 

OK. 

 

Mike> Done =E2=80=93 thanks!

 

Privacy Consideration

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

It is missing privacy consideration. It is not required per = se, but since Key Confirmation method with ephemeral key can be less = privacy intrusive compared to other sender confirmation method so adding = some text around it may be a good = idea. 

 

Can you supply some specific proposed text for -04?

 

When do you expect = -04? 

Depending on it, I may be able = to. 

 

Mike> I wrote a Privacy Considerations section, addressing the use = of confirmation keys as correlation handles.

 

 

Best, 

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 

Thanks again for your useful review comments!

 

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

 



 

--

Nat Sakimura = (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 

            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   Thanks again, Nat!

            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   -- Mike

 

<= /html> ------=_NextPart_000_03A6_01D0E4E9.DD565580-- From nobody Tue Sep 1 08:13:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78421B2F99 for ; Tue, 1 Sep 2015 08:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxRfkCFYRNwL for ; Tue, 1 Sep 2015 08:13:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1121B324B for ; Tue, 1 Sep 2015 08:13:48 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t81FDjno013421 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Sep 2015 15:13:46 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t81FDjPr003020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2015 15:13:45 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t81FDjmd004820; Tue, 1 Sep 2015 15:13:45 GMT Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Sep 2015 08:13:45 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: <55E544A6.3050203@gmx.net> Date: Tue, 1 Sep 2015 08:13:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <514ABD00-586C-4ABC-A867-698CBC50DA79@oracle.com> References: <20150901045617.CB44D187A98@rfc-editor.org> <55E544A6.3050203@gmx.net> To: Hannes Tschofenig X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 15:13:50 -0000 +1 ! Phil > On Aug 31, 2015, at 23:24, Hannes Tschofenig w= rote: >=20 > FYI: Thanks to Bill for the hard work! >=20 > -------- Forwarded Message -------- > Subject: RFC 7628 on A Set of Simple Authentication and Security Layer > (SASL) Mechanisms for OAuth > Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT) > From: rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > CC: kitten@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org= >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7628 >=20 > Title: A Set of Simple Authentication > and Security Layer (SASL) Mechanisms > for OAuth > Author: W. Mills, T. Showalter, H. Tschofenig > Status: Standards Track > Stream: IETF > Date: August 2015 > Mailbox: wmills_92105@yahoo.com, > tjs@psaux.com, > Hannes.Tschofenig@gmx.net > Pages: 21 > Characters: 46408 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt >=20 > URL: https://www.rfc-editor.org/info/rfc7628 >=20 > DOI: http://dx.doi.org/10.17487/RFC7628 >=20 > OAuth enables a third-party application to obtain limited access to a > protected resource, either on behalf of a resource owner by > orchestrating an approval interaction or by allowing the third-party > application to obtain access on its own behalf. >=20 > This document defines how an application client uses credentials > obtained via OAuth over the Simple Authentication and Security Layer > (SASL) to access a protected resource at a resource server. Thereby, > it enables schemes defined within the OAuth framework for > non-HTTP-based application protocols. >=20 > Clients typically store the user's long-term credential. This does, > however, lead to significant security vulnerabilities, for example, > when such a credential leaks. A significant benefit of OAuth for > usage in those clients is that the password is replaced by a shared > secret with higher entropy, i.e., the token. Tokens typically > provide limited access rights and can be managed and revoked > separately from the user's long-term password. >=20 > This document is a product of the Common Authentication Technology Next > Generation Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestio= ns > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the= > standardization state and status of this protocol. Distribution of this > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Sep 1 08:44:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B811B4D02 for ; Tue, 1 Sep 2015 08:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0TMOijNeR3H for ; Tue, 1 Sep 2015 08:44:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9601B3DA6 for ; Tue, 1 Sep 2015 08:44:14 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.1.243.23; Tue, 1 Sep 2015 15:44:13 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0243.024; Tue, 1 Sep 2015 15:44:12 +0000 From: Mike Jones To: Bill Mills , Phil Hunt , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth Thread-Index: AQHQ5Ir75W0PLpZNOkaEhwVtHuhg4J4nyH8AgAAH7bA= Date: Tue, 1 Sep 2015 15:44:12 +0000 Message-ID: References: <20150901045617.CB44D187A98@rfc-editor.org> <55E544A6.3050203@gmx.net> <514ABD00-586C-4ABC-A867-698CBC50DA79@oracle.com> In-Reply-To: <514ABD00-586C-4ABC-A867-698CBC50DA79@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.89.201] x-microsoft-exchange-diagnostics: 1; BY2PR03MB411; 5:Bgxe/s1Bg1hD9n3cMHHtWdudCBNPrADo86iI4vtBS32MNeBQ5sbZqeRQ7cAZU9vI/0DoEXrX42rLg9gBhD56p4fjrfpQfZvU5bBmjWfxNSSc1Q+/L5OdDWRwdsj3WQwkwcE7wxGz6SJourLbEUwz3Q==; 24:nc17m5D9dqN/cWZ2wZomOTj+got/Lu02MwUARipN6j91UiOuee+wgLIMnlrJQvFagc993ceczMatQcLL15B5dZxooUVFhTU6DCK1ovwLhGg=; 20:bzK/2dgjkIYyeymXWZ7eusuWeBocn9yGB93DeBb+VwoMBmk9jpLfZhp60AFT8xaxAFPqM9sE+OP3JtYx1iiGnQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:BY2PR03MB411; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BY2PR03MB411; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB411; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2473001)(15594002)(189002)(69234005)(377454003)(13464003)(24454002)(199003)(86612001)(74316001)(33656002)(19580395003)(19580405001)(5002640100001)(5880100001)(2656002)(5001960100002)(189998001)(5003600100002)(5001830100001)(64706001)(4001540100001)(551544002)(5007970100001)(5004730100002)(81156007)(97736004)(5001860100001)(105586002)(5001770100001)(106116001)(575784001)(99286002)(106356001)(86362001)(15975445007)(2421001)(102836002)(10090500001)(87936001)(77096005)(68736005)(62966003)(46102003)(5005710100001)(10290500002)(10400500002)(8990500004)(101416001)(50986999)(66066001)(54356999)(76176999)(92566002)(2561002)(122556002)(40100003)(2950100001)(76576001)(2900100001)(1511001)(77156002)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2015 15:44:12.3693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB411 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 15:44:16 -0000 Congratulations, Bill! -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, September 01, 2015 8:14 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and= Security Layer (SASL) Mechanisms for OAuth +1 ! Phil > On Aug 31, 2015, at 23:24, Hannes Tschofenig = wrote: >=20 > FYI: Thanks to Bill for the hard work! >=20 > -------- Forwarded Message -------- > Subject: RFC 7628 on A Set of Simple Authentication and Security Layer > (SASL) Mechanisms for OAuth > Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT) > From: rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > CC: kitten@ietf.org, drafts-update-ref@iana.org,=20 > rfc-editor@rfc-editor.org >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7628 >=20 > Title: A Set of Simple Authentication > and Security Layer (SASL) Mechanisms > for OAuth > Author: W. Mills, T. Showalter, H. Tschofenig > Status: Standards Track > Stream: IETF > Date: August 2015 > Mailbox: wmills_92105@yahoo.com, > tjs@psaux.com, > Hannes.Tschofenig@gmx.net > Pages: 21 > Characters: 46408 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt >=20 > URL: https://na01.safelinks.protection.outlook.com/?url=3Dh= ttps%3a%2f%2fwww.rfc-editor.org%2finfo%2frfc7628&data=3D01%7c01%7cMichael.J= ones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af9= 1ab2d7cd011db47%7c1&sdata=3DJ1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d >=20 > DOI: https://na01.safelinks.protection.outlook.com/?url=3Dh= ttp%3a%2f%2fdx.doi.org%2f10.17487%2fRFC7628&data=3D01%7c01%7cMichael.Jones%= 40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d= 7cd011db47%7c1&sdata=3D%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d >=20 > OAuth enables a third-party application to obtain limited access to a=20 > protected resource, either on behalf of a resource owner by=20 > orchestrating an approval interaction or by allowing the third-party=20 > application to obtain access on its own behalf. >=20 > This document defines how an application client uses credentials=20 > obtained via OAuth over the Simple Authentication and Security Layer > (SASL) to access a protected resource at a resource server. Thereby,=20 > it enables schemes defined within the OAuth framework for=20 > non-HTTP-based application protocols. >=20 > Clients typically store the user's long-term credential. This does,=20 > however, lead to significant security vulnerabilities, for example,=20 > when such a credential leaks. A significant benefit of OAuth for=20 > usage in those clients is that the password is replaced by a shared=20 > secret with higher entropy, i.e., the token. Tokens typically provide=20 > limited access rights and can be managed and revoked separately from=20 > the user's long-term password. >=20 > This document is a product of the Common Authentication Technology=20 > Next Generation Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track=20 > protocol for the Internet community, and requests discussion and=20 > suggestions for improvements. Please refer to the current edition of=20 > the Official Internet Protocol Standards=20 > (https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. > rfc-editor.org%2fstandards&data=3D01%7c01%7cMichael.Jones%40microsoft.com= %7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&= sdata=3D7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5vijFPU%3d) for the standardi= zation state and status of this protocol. Distribution of this memo is unl= imited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > =20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2fietf-announce&data=3D01%7c01%7cMichael.Jo > nes%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f14 > 1af91ab2d7cd011db47%7c1&sdata=3DaGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ5t > WbEkg%3d =20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fmailm > an.rfc-editor.org%2fmailman%2flistinfo%2frfc-dist&data=3D01%7c01%7cMicha > el.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf > 86f141af91ab2d7cd011db47%7c1&sdata=3Dagec9juMh0Zzn1mrY6avpBrLPlFfCs8zsyx > 8bSLgDdc%3d >=20 > For searching the RFC series, see=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r > fc-editor.org%2fsearch&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c > 9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c > 1&sdata=3DveVw3wrA9Wz6CWTUfVTLCKAdduFgUDkiaabcuqFyRxc%3d > For downloading RFCs, see=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r > fc-editor.org%2frfc.html&data=3D01%7c01%7cMichael.Jones%40microsoft.com% > 7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47% > 7c1&sdata=3D93atgoSh8enZBPOxNfMophuutPvidnrfoMxOc0XmjS8%3d >=20 > Requests for special distribution should be addressed to either the=20 > author of the RFC in question, or to rfc-editor@rfc-editor.org. =20 > Unless specifically noted otherwise on the RFC itself, all RFCs are=20 > for unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40mi > crosoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2 > d7cd011db47%7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU% > 3d _______________________________________________ OAuth mailing list OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40microsof= t.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47= %7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%3d From nobody Tue Sep 1 09:03:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7A61B3716 for ; Tue, 1 Sep 2015 09:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j09dik5lEOAm for ; Tue, 1 Sep 2015 09:03:49 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A361B41E5 for ; Tue, 1 Sep 2015 09:03:43 -0700 (PDT) Received: from [80.187.113.166] (helo=[10.42.51.78]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1ZWo28-0005of-HC; Tue, 01 Sep 2015 18:03:41 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <20150901045617.CB44D187A98@rfc-editor.org> <55E544A6.3050203@gmx.net> <514ABD00-586C-4ABC-A867-698CBC50DA79@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----F14VEAD3DIJ6UF5IHLNN6OG8CTR6BK" Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Tue, 01 Sep 2015 17:56:29 +0200 To: Mike Jones , Bill Mills , Phil Hunt , Hannes Tschofenig Message-ID: <4FCA2B2B-8AF8-464D-91ED-793D295C8DCB@lodderstedt.net> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:03:54 -0000 ------F14VEAD3DIJ6UF5IHLNN6OG8CTR6BK Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 +1 Am 1. September 2015 17:44:12 MESZ, schrieb Mike Jones : >Congratulations, Bill! > >-----Original Message----- >From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >Sent: Tuesday, September 01, 2015 8:14 AM >To: Hannes Tschofenig >Cc: oauth@ietf.org >Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication >and Security Layer (SASL) Mechanisms for OAuth > >+1 ! > >Phil > >> On Aug 31, 2015, at 23:24, Hannes Tschofenig > wrote: >> >> FYI: Thanks to Bill for the hard work! >> >> -------- Forwarded Message -------- >> Subject: RFC 7628 on A Set of Simple Authentication and Security >Layer >> (SASL) Mechanisms for OAuth >> Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT) >> From: rfc-editor@rfc-editor.org >> Reply-To: ietf@ietf.org >> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org >> CC: kitten@ietf.org, drafts-update-ref@iana.org, >> rfc-editor@rfc-editor.org >> >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 7628 >> >> Title: A Set of Simple Authentication >> and Security Layer (SASL) Mechanisms >> for OAuth >> Author: W. Mills, T. Showalter, H. Tschofenig >> Status: Standards Track >> Stream: IETF >> Date: August 2015 >> Mailbox: wmills_92105@yahoo.com, >> tjs@psaux.com, >> Hannes.Tschofenig@gmx.net >> Pages: 21 >> Characters: 46408 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt >> >> URL: >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.rfc-editor.org%2finfo%2frfc7628&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=J1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d >> >> DOI: >https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdx.doi.org%2f10.17487%2fRFC7628&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d >> >> OAuth enables a third-party application to obtain limited access to a > >> protected resource, either on behalf of a resource owner by >> orchestrating an approval interaction or by allowing the third-party >> application to obtain access on its own behalf. >> >> This document defines how an application client uses credentials >> obtained via OAuth over the Simple Authentication and Security Layer >> (SASL) to access a protected resource at a resource server. Thereby, > >> it enables schemes defined within the OAuth framework for >> non-HTTP-based application protocols. >> >> Clients typically store the user's long-term credential. This does, >> however, lead to significant security vulnerabilities, for example, >> when such a credential leaks. A significant benefit of OAuth for >> usage in those clients is that the password is replaced by a shared >> secret with higher entropy, i.e., the token. Tokens typically >provide >> limited access rights and can be managed and revoked separately from >> the user's long-term password. >> >> This document is a product of the Common Authentication Technology >> Next Generation Working Group of the IETF. >> >> This is now a Proposed Standard. >> >> STANDARDS TRACK: This document specifies an Internet Standards Track >> protocol for the Internet community, and requests discussion and >> suggestions for improvements. Please refer to the current edition of > >> the Official Internet Protocol Standards >> >(https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >> >rfc-editor.org%2fstandards&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5vijFPU%3d) >for the standardization state and status of this protocol. >Distribution of this memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> >> >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i >> >etf.org%2fmailman%2flistinfo%2fietf-announce&data=01%7c01%7cMichael.Jo >> >nes%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f14 >> >1af91ab2d7cd011db47%7c1&sdata=aGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ5t >> WbEkg%3d >> >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmailm >> >an.rfc-editor.org%2fmailman%2flistinfo%2frfc-dist&data=01%7c01%7cMicha >> >el.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf >> >86f141af91ab2d7cd011db47%7c1&sdata=agec9juMh0Zzn1mrY6avpBrLPlFfCs8zsyx >> 8bSLgDdc%3d >> >> For searching the RFC series, see >> >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.r >> >fc-editor.org%2fsearch&data=01%7c01%7cMichael.Jones%40microsoft.com%7c >> >9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c >> 1&sdata=veVw3wrA9Wz6CWTUfVTLCKAdduFgUDkiaabcuqFyRxc%3d >> For downloading RFCs, see >> >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.r >> >fc-editor.org%2frfc.html&data=01%7c01%7cMichael.Jones%40microsoft.com% >> >7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47% >> 7c1&sdata=93atgoSh8enZBPOxNfMophuutPvidnrfoMxOc0XmjS8%3d >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. >> Unless specifically noted otherwise on the RFC itself, all RFCs are >> for unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i >> >etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40mi >> >crosoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2 >> >d7cd011db47%7c1&sdata=ILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU% >> 3d > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%3d > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth ------F14VEAD3DIJ6UF5IHLNN6OG8CTR6BK Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1

Am 1. September 2015 17:44:12 MESZ, schrieb Mike Jones <Michael.Jones@microsoft.com>:
Congratulations, Bill!

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, September 01, 2015 8:14 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth

+1 !

Phil

 On Aug 31, 2015, at 23:24, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
 
 FYI: Thanks to Bill for the hard work!
 
 -------- Forwarded Message --------
 Subject: RFC 7628 on A Set of Simple Authentication and Security Layer
 (SASL) Mechanisms for OAuth
 Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT)
 From: rfc-editor@rfc-editor.org
 Reply-To: ietf@ietf.org
 To: ietf-announce@ietf.org,
rfc-dist@rfc-editor.org
 CC: kitten@ietf.org, drafts-update-ref@iana.org, 
 rfc-editor@rfc-editor.org
 
 A new Request for Comments is now available in online RFC libraries.
 
 
        RFC 7628
 
        Title:      A Set of Simple Authentication
                    and Security Layer (SASL) Mechanisms
                    for OAuth
        Author:     W. Mills, T. Showalter, H. Tschofenig
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2015
        Mailbox:    wmills_92105@yahoo.com,
                    tjs@psaux.com,
                    Hannes.Tschofenig@gmx.net
        Pages:      21
        Characters: 46408
        Updates/Obsoletes/SeeAlso:   None
 
        I-D Tag:    draft-ietf-kitten-sasl-oauth-23.txt
 
        URL:        https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.rfc-editor.org%2finfo%2frfc7628&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=J1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d
 
        DOI:        https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdx.doi.org%2f10.17487%2fRFC7628&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d
 
 OAuth enables a third-party application to obtain limited access to a 
 protected resource, either on behalf of a resource owner by 
 orchestrating an approval interaction or by allowing the third-party 
 application to obtain access on its own behalf.
 
 This document defines how an application client uses credentials 
 obtained via OAuth over the Simple Authentication and Security
Layer
 (SASL) to access a protected resource at a resource server.  Thereby, 
 it enables schemes defined within the OAuth framework for 
 non-HTTP-based application protocols.
 
 Clients typically store the user's long-term credential.  This does, 
 however, lead to significant security vulnerabilities, for example, 
 when such a credential leaks.  A significant benefit of OAuth for 
 usage in those clients is that the password is replaced by a shared 
 secret with higher entropy, i.e., the token.  Tokens typically provide 
 limited access rights and can be managed and revoked separately from 
 the user's long-term password.
 
 This document is a product of the Common Authentication Technology 
 Next Generation Working Group of the IETF.
 
 This is now a Proposed Standard.
 
 STANDARDS TRACK: This document specifies an Internet Standards Track 
 protocol for the Internet community, and
requests discussion and 
 suggestions for improvements.  Please refer to the current edition of 
 the Official Internet Protocol Standards 
 (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
 rfc-editor.org%2fstandards&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5vijFPU%3d) for the standardization state and status of this protocol.  Distribution of this memo is unlimited.
 
 This announcement is sent to the IETF-Announce and rfc-dist lists.
 To subscribe or unsubscribe, see
  
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
 etf.org%2fmailman%2flistinfo%2fietf-announce&data=01%7c01%7cMichael.Jo
 nes%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f14
 1af91ab2d7cd011db47%7c1&sdata=aGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ5t
 WbEkg%3d  
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmailm
 an.rfc-editor.org%2fmailman%2flistinfo%2frfc-dist&data=01%7c01%7cMicha
 el.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf
 86f141af91ab2d7cd011db47%7c1&sdata=agec9juMh0Zzn1mrY6avpBrLPlFfCs8zsyx
 8bSLgDdc%3d
 
 For searching the RFC series, see 
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.r
 fc-editor.org%2fsearch&data=01%7c01%7cMichael.Jones%40microsoft.com%7c
 9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c
 1&sdata=veVw3wrA9Wz6CWTUfVTLCKAdduFgUDkiaabcuqFyRxc%3d
 For downloading RFCs, see 
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.r
 fc-editor.org%2frfc.html&data=01%7c01%7cMichael.Jones%40microsoft.com%
 7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%
 7c1&sdata=93atgoSh8enZBPOxNfMophuutPvidnrfoMxOc0XmjS8%3d
 
 Requests for special distribution should be
addressed to either the 
 author of the RFC in question, or to rfc-editor@rfc-editor.org.  
 Unless specifically noted otherwise on the RFC itself, all RFCs are 
 for unlimited distribution.
 
 
 The RFC Editor Team
 Association Management Solutions, LLC
 
 
 
 
 

 OAuth mailing list
 OAuth@ietf.org
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
 etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40mi
 crosoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2
 d7cd011db47%7c1&sdata=ILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%
 3d


OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%3d


OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------F14VEAD3DIJ6UF5IHLNN6OG8CTR6BK-- From nobody Tue Sep 1 09:37:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345A11B523B for ; Tue, 1 Sep 2015 09:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gysdfdl7ZWFp for ; Tue, 1 Sep 2015 09:37:12 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A65B1B5366 for ; Tue, 1 Sep 2015 09:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441125431; bh=obDAR2T9HAGaZXDB4+QTYDBlTHuRs1IEGCKBDzLQNPg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=CI6pAV7z7mnJYlket+gwNq0bFj47gmv9EGwYtIkoilUeJ6/bTQ6vfyv912rg2iw91HTj0Zfoz6Y/LNXdKlM89GbARidmy6hsuq4c/uwC4YCL7R1hobcr+RyvjD7JGdr9lMChR5/YQdfwEqZtHCuZ2QtdBkWRAwAV2VWEqvZiwXic6qoS/enqSGv81GS7d9j2aHCuOMHA85MxHi/W0QM8fkEmTWeamhWe2Oj+Liw0odTK045FvNHn7zaR11dEodsxjNNz5vgFujy6VZUogY/Nr7lJUrCEVrIttgurzwDZG0Y0RbxLokmmbMYzuNi9FVhcajmQCK0HEsWm+7aPRt+ZhA== Received: from [98.139.170.182] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 01 Sep 2015 16:37:11 -0000 Received: from [98.139.212.205] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 01 Sep 2015 16:37:11 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 01 Sep 2015 16:37:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 299857.69342.bm@omp1014.mail.bf1.yahoo.com X-YMail-OSG: yBhoZUAVM1kU4ji9iBNts0E.wnyxnctnW1EBfqiIJ5L3dqIWU06FG6JcDxJ6dDz irRrz3HxEFKPG90hFxdPUWG1aIefXhQDr7H_xpMqoKAHIRy7xwQXiS.qSR0FZn.ScEWnN13uozCa tuv79kJm5TCvytQw8ygW17_WAHnZ5CrENgEvEfSrGVo9F0P4a5e_AT40kImLZSvk3btyjzceXWJF 9JDIW5VfBW8UaG7LaKPWQK_rUAK4NLV98W9Ag5fBg0vX3SwkJJgfZOGoAjcpGTtOFXPcudiyxgaU hgLT24Vj2dJWkZZsAUtFNMioLJyfDw3iux9adrW2brE2YhRdzukL7d7MBf.hWWFj3Aaqc8XXft6T C_8JjneD.XbAVfCYATqshAOXxweSnLR.8sclxo6Au3CA_47Ryzl3sAkSMt38HxGmR7udMEvnOIV. bUYIu072H3K8loCJdr8KM8kvGSdrqK3DsiV1xANOGu33bH1to03_w9VAwhi_JM06Fo6JM_IPsZtD NDkBKvTUl.MpPKmMvRpLgSpmvshpHugujoc8cDWndLHJgRg-- Received: by 66.196.81.119; Tue, 01 Sep 2015 16:37:10 +0000 Date: Tue, 1 Sep 2015 16:37:10 +0000 (UTC) From: Bill Mills To: Torsten Lodderstedt , Mike Jones , Bill Mills , Phil Hunt , Hannes Tschofenig Message-ID: <553525297.4176073.1441125430398.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <4FCA2B2B-8AF8-464D-91ED-793D295C8DCB@lodderstedt.net> References: <4FCA2B2B-8AF8-464D-91ED-793D295C8DCB@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4176072_1886219246.1441125430390" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:37:16 -0000 ------=_Part_4176072_1886219246.1441125430390 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And thank you Hannes for all the guidance and being agreat collaborator on = this! =C2=A0 And to the WG, chairs, and shepherds, we did somethinggood here.=C2=A0 Than= k you all for the review,attention, time, and your help as well. =C2=A0 -bill =20 On Tuesday, September 1, 2015 9:04 AM, Torsten Lodderstedt wrote: =20 +1 Am 1. September 2015 17:44:12 MESZ, schrieb Mike Jones : Congratulations, Bill! -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, September 01, 2015 8:14 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and= Security Layer (SASL) Mechanisms for OAuth +1 ! Phil On Aug 31, 2015, at 23:24, Hannes Tschofenig w= rote: =20 FYI: Thanks to Bill for the hard work! =20 -------- Forwarded Message -------- Subject: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org,rfc-dist@rfc-editor.org CC: kitten@ietf.org, drafts-update-ref@iana.org,=20 rfc-editor@rfc-editor.org =20 A new Request for Comments is now available in online RFC libraries. =20 =20 RFC 7628 =20 Title: A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth Author: W. Mills, T. Showalter, H. Tschofenig Status: Standards Track Stream: IETF Date: August 2015 Mailbox: wmills_92105@yahoo.com, tjs@psaux.com, Hannes.Tschofenig@gmx.net Pages: 21 Characters: 46408 Updates/Obsoletes/SeeAlso: None =20 I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt =20 URL: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww= w.rfc-editor.org%2finfo%2frfc7628&data=3D01%7c01%7cMichael.Jones%40microsof= t.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47= %7c1&sdata=3DJ1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d =20 DOI: https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fdx.= doi.org%2f10.17487%2fRFC7628&data=3D01%7c01%7cMichael.Jones%40microsoft.com= %7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&= sdata=3D%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d =20 OAuth enables a third-party application to obtain limited access to a=20 protected resource, either on behalf of a resource owner by=20 orchestrating an approval interaction or by allowing the third-party=20 application to obtain access on its own behalf. =20 This document defines how an application client uses credentials=20 obtained via OAuth over the Simple Authentication and SecurityLayer (SASL) to access a protected resource at a resource server. Thereby,=20 it enables schemes defined within the OAuth framework for=20 non-HTTP-based application protocols. =20 Clients typically store the user's long-term credential. This does,=20 however, lead to significant security vulnerabilities, for example,=20 when such a credential leaks. A significant benefit of OAuth for=20 usage in those clients is that the password is replaced by a shared=20 secret with higher entropy, i.e., the token. Tokens typically provide=20 limited access rights and can be managed and revoked separately from=20 the user's long-term password. =20 This document is a product of the Common Authentication Technology=20 Next Generation Working Group of the IETF. =20 This is now a Proposed Standard. =20 STANDARDS TRACK: This document specifies an Internet Standards Track=20 protocol for the Internet community, andrequests discussion and=20 suggestions for improvements. Please refer to the current edition of=20 the Official Internet Protocol Standards=20 (https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. rfc-editor.org%2fstandards&data=3D01%7c01%7cMichael.Jones%40microsoft.com%= 7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&s= data=3D7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5vijFPU%3d) for the standardiz= ation state and status of this protocol. Distribution of this memo is unlim= ited. =20 This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see =20 https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i etf.org%2fmailman%2flistinfo%2fietf-announce&data=3D01%7c01%7cMichael.Jo nes%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f14 1af91ab2d7cd011db47%7c1&sdata=3DaGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ5t WbEkg%3d=20 https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fmailm an.rfc-editor.org%2fmailman%2flistinfo%2frfc-dist&data=3D01%7c01%7cMicha el.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf 86f141af91ab2d7cd011db47%7c1&sdata=3Dagec9juMh0Zzn1mrY6avpBrLPlFfCs8zsyx 8bSLgDdc%3d =20 For searching the RFC series, see=20 https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r fc-editor.org%2fsearch&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c 9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c 1&sdata=3DveVw3wrA9Wz6CWTUfVTLCKAdduFgUDkiaabcuqFyRxc%3d For downloading RFCs, see=20 https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r fc-editor.org%2frfc.html&data=3D01%7c01%7cMichael.Jones%40microsoft.com% 7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47% 7c1&sdata=3D93atgoSh8enZBPOxNfMophuutPvidnrfoMxOc0XmjS8%3d =20 Requests for special distribution should beaddressed to either the=20 author of the RFC in question, or to rfc-editor@rfc-editor.org.=20 Unless specifically noted otherwise on the RFC itself, all RFCs are=20 for unlimited distribution. =20 =20 The RFC Editor Team Association Management Solutions, LLC =20 =20 =20 =20 =20 OAuth mailing list OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40mi crosoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2 d7cd011db47%7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU% 3d OAuth mailing list OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40microsof= t.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47= %7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%3d OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_4176072_1886219246.1441125430390 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And = thank you Hannes for all the guidance and being a great collaborator on this!
 
And to the WG, = chairs, and shepherds, we did something good here.  Thank you all for the review, attention, time, and your help as well.
&nb= sp;
= -bill
=


=
On Tuesday, September 1, 2015 9:04 AM, Torsten Lodde= rstedt <torsten@lodderstedt.net> wrote:


=
+1

Am 1. = September 2015 17:44:12 MESZ, schrieb Mike Jones <Michael.Jones@microsof= t.com>:
Congratulations, Bill!

-----Original Message-----
From: OAut=
h [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
=
Sent: Tuesday, September 01, 2015 8:14 AM
To: Hannes Tsch=
ofenig
Cc: oauth@ietf.org
Subject: Re: =
[OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Lay=
er (SASL) Mechanisms for OAuth

+1 !
Phil

On Aug 31, = 2015, at 23:24, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:<= br clear=3D"none">
FYI: Thanks to Bill for the hard wor= k!

-------- Forwarded Message ------= --
Subject: RFC 7628 on A Set of Simple Authentication a= nd Security Layer
(SASL) Mechanisms for OAuth
Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT)
F= rom: rfc-editor@rfc-editor.org
Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: kitten@ietf.org, drafts-upda= te-ref@iana.org,
rfc-editor@rfc-editor.org

A new Request for Comments is now available in o= nline RFC libraries.


RFC 7628

Title: = A Set of Simple Authentication
an= d Security Layer (SASL) Mechanisms
fo= r OAuth
Author: W. Mills, T. Showalter, H. Ts= chofenig
Status: Standards Track
Stream: IETF
Date: August= 2015
Mailbox: wmills_92105@yahoo.com,
tjs@psaux.com,
= Hannes.Tschofenig@gmx.net
Pages: 21=
Characters: 46408
Upda= tes/Obsoletes/SeeAlso: None

= I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt

URL: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2f= www.rfc-editor.org%2finfo%2frfc7628&data=3D01%7c01%7cMichael.Jones%40mi= crosoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd0= 11db47%7c1&sdata=3DJ1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d
DOI: https://na01.safelinks.protection.outlook.com/= ?url=3Dhttp%3a%2f%2fdx.doi.org%2f10.17487%2fRFC7628&data=3D01%7c01%7cMi= chael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3D%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwed= zfrx0xKUE%3d

OAuth enables a thi= rd-party application to obtain limited access to a
prot= ected resource, either on behalf of a resource owner by
= orchestrating an approval interaction or by allowing the third-party
application to obtain access on its own behalf.

This document defines how an application client = uses credentials
obtained via OAuth over the Simple Aut= hentication and Security Layer
(SASL) to access a protected resource at a resourc= e server. Thereby,
it enables schemes defined within t= he OAuth framework for
non-HTTP-based application proto= cols.

Clients typically store the us= er's long-term credential. This does,
however, lead to= significant security vulnerabilities, for example,
whe= n such a credential leaks. A significant benefit of OAuth for
usage in those clients is that the password is replaced by a shared=
secret with higher entropy, i.e., the token. Tokens t= ypically provide
limited access rights and can be manag= ed and revoked separately from
the user's long-term pas= sword.

This document is a product of= the Common Authentication Technology
Next Generation W= orking Group of the IETF.

This is no= w a Proposed Standard.

STANDARDS TRA= CK: This document specifies an Internet Standards Track
= protocol for the Internet community, and requests discussion and
suggestions for improvements. = Please refer to the current edition of
the Official Int= ernet Protocol Standards
(https://na01.safelinks.protection.outlook.com/= ?url=3Dhttps%3a%2f%2fwww.
rfc-editor.org<= /a>%2fstandards&data=3D01%7c01%7cMichael.Jones%40microsoft.c= om%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3D7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5vijFPU%3d) for the= standardization state and status of this protocol. Distribution of this m= emo is unlimited.

This announcement = is sent to the IETF-Announce and rfc-dist lists.
To subs= cribe or unsubscribe, see

https://na01.safelinks.p= rotection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i
= etf.org%2fmailman%2flistinfo%2fietf-announce&data=3D01%7c01%7cMicha= el.Jo
nes%40microsoft.com%7c9f19ef0544aa4= 990d83f08d2b2dff4a3%7c72f988bf86f14
1af91ab2d7cd011db47%= 7c1&sdata=3DaGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ5t
= WbEkg%3d
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3a%2f%2fmailm
an.rfc-editor.org%2fm= ailman%2flistinfo%2frfc-dist&data=3D01%7c01%7cMicha
= el.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%= 7c72f988bf
86f141af91ab2d7cd011db47%7c1&sdata=3Dagec= 9juMh0Zzn1mrY6avpBrLPlFfCs8zsyx
8bSLgDdc%3d

For searching the RFC series, see
https://n= a01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r
fc-editor.org%2fsearch&data=3D01%7c01%7cMichae= l.Jones%40microsoft.com%7c
9f19ef0544aa49= 90d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c
= 1&sdata=3DveVw3wrA9Wz6CWTUfVTLCKAdduFgUDkiaabcuqFyRxc%3d
For downloading RFCs, see
https://na01.safelinks.protection.outl= ook.com/?url=3Dhttps%3a%2f%2fwww.r
fc-edito= r.org%2frfc.html&data=3D01%7c01%7cMichael.Jones%40micros= oft.com%
7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988= bf86f141af91ab2d7cd011db47%
7c1&sdata=3D93atgoSh8enZ= BPOxNfMophuutPvidnrfoMxOc0XmjS8%3d

R= equests for special distribution should be addressed to either the
author of the RFC in question, = or to rfc-editor@rfc-editor.org.
Unless specifically n= oted otherwise on the RFC itself, all RFCs are
for unli= mited distribution.


The RFC Editor Team
Association Management Solutions= , LLC






O= Auth mailing list
OAuth@ietf.org
https://na01.safeli= nks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i
etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.= Jones%40mi
crosoft.com%7c9f19ef0544aa4990d83f= 08d2b2dff4a3%7c72f988bf86f141af91ab2
d7cd011db47%7c1&= ;sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%
3d


OAuth mailing list
OAuth@ietf.org
https://na01.safel= inks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2fl= istinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef= 0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata= =3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%3d


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

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


------=_Part_4176072_1886219246.1441125430390-- From nobody Tue Sep 1 11:00:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3501B66AD for ; Tue, 1 Sep 2015 10:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuEm1JTqzV3o for ; Tue, 1 Sep 2015 10:59:53 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577021B4F54 for ; Tue, 1 Sep 2015 10:59:53 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-fc-55e5e797b70c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 26.23.21268.797E5E55; Tue, 1 Sep 2015 13:59:51 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t81HxogA028744; Tue, 1 Sep 2015 13:59:50 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t81HxixU000787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2015 13:59:48 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_F0265934-B26B-4E2F-99D8-CD94E5422395" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <553525297.4176073.1441125430398.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 1 Sep 2015 13:59:44 -0400 Message-Id: References: <4FCA2B2B-8AF8-464D-91ED-793D295C8DCB@lodderstedt.net> <553525297.4176073.1441125430398.JavaMail.yahoo@mail.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsUixCmqrDv9+dNQg9cndC2W7rzHarF32icW i5NvX7FZLJjfyG7x6thTFot7bycyWXzrus7swO6xeNN+No8lS34yeRzr6Wf1aN3xl93j49Nb LB6zZh1mCmCL4rJJSc3JLEst0rdL4Mp4t3EpY0HnU8aK/1PPsTYwrjnD2MXIySEhYCLR3rcQ yhaTuHBvPVsXIxeHkMBiJonnfycwQTgbGCWWf17FDuE8YJKYs+YmE0gLs0CCxJMLrewgNq+A nsSrW5dZQWxhgUKJr6tWsIHYbAKqEtPXtIDVcwr4SNxfcIQZxGYRUJHoPruIGWQos8BMJolF 2xpYIAZZSazd+IYZYlsTo0TH6m9AB3JwiAioSzR/94a4VVZi9+9HTBMYBWYhuWMWkjsg4toS yxa+ZoawNSX2dy9nwRTXkOj8NpF1ASPbKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3U lNJNjOCYkuTdwfjuoNIhRgEORiUe3o6PT0KFWBPLiitzDzFKcjApifL+f/g0VIgvKT+lMiOx OCO+qDQntfgQowQHs5IIb8RhoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpis DAeHkgTvhGdAjYJFqempFWmZOSUIaSYOTpDhPEDDj4HU8BYXJOYWZ6ZD5E8xKkqJ8557CpQQ AElklObB9cJS3itGcaBXhHk1QNp5gOkSrvsV0GAmoMHTXcEGlyQipKQaGJVySzvKbm56Z7Yz ym3j9D09JwI+PrpYsYNZtJclROrcz6OGTQ1XStwXibgd61vto3HFcnXGggaXxwXpBdHX7SZs NlltstkgPzLPR79QKnCbxpTeJ13PbURUzv6QXR/zvjznQHb9obp5L9m3RD9eZPj7jUjAhvbK Y6nzV+mIvzxkX/xeeta030osxRmJhlrMRcWJAD4zevZUAwAA Archived-At: Cc: Bill Mills , "" Subject: Re: [OAUTH-WG] RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:59:58 -0000 --Apple-Mail=_F0265934-B26B-4E2F-99D8-CD94E5422395 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hooray, congratulations! =E2=80=94 Justin > On Sep 1, 2015, at 12:37 PM, Bill Mills = wrote: >=20 > And thank you Hannes for all the guidance and being a great = collaborator on this! > =20 > And to the WG, chairs, and shepherds, we did something good here. = Thank you all for the review, attention, time, and your help as well. > =20 > -bill >=20 >=20 >=20 > On Tuesday, September 1, 2015 9:04 AM, Torsten Lodderstedt = wrote: >=20 >=20 > +1 >=20 > Am 1. September 2015 17:44:12 MESZ, schrieb Mike Jones = : > Congratulations, Bill! >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Tuesday, September 01, 2015 8:14 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple = Authentication and Security Layer (SASL) Mechanisms for OAuth >=20 > +1 ! >=20 > Phil >=20 > On Aug 31, 2015, at 23:24, Hannes Tschofenig = wrote: >=20 > FYI: Thanks to Bill for the hard work! >=20 > -------- Forwarded Message -------- > Subject: RFC 7628 on A Set of Simple Authentication and Security Layer > (SASL) Mechanisms for OAuth > Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT) > From: rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > CC: kitten@ietf.org, drafts-update-ref@iana.org,=20 > rfc-editor@rfc-editor.org >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7628 >=20 > Title: A Set of Simple Authentication > and Security Layer (SASL) Mechanisms > for OAuth > Author: W. Mills, T. Showalter, H. Tschofenig > Status: Standards Track > Stream: IETF > Date: August 2015 > Mailbox: wmills_92105@yahoo.com, > tjs@psaux.com, > Hannes.Tschofenig@gmx.net > Pages: 21 > Characters: 46408 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt >=20 > URL: = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.rfc= -editor.org%2finfo%2frfc7628&data=3D01%7c01%7cMichael.Jones%40microsoft.co= m%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3DJ1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d = >=20 > DOI: = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fdx.doi.o= rg%2f10.17487%2fRFC7628&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c9= f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda= ta=3D%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d = >=20 > OAuth enables a third-party application to obtain limited access to a=20= > protected resource, either on behalf of a resource owner by=20 > orchestrating an approval interaction or by allowing the third-party=20= > application to obtain access on its own behalf. >=20 > This document defines how an application client uses credentials=20 > obtained via OAuth over the Simple Authentication and Security Layer > (SASL) to access a protected resource at a resource server. Thereby,=20= > it enables schemes defined within the OAuth framework for=20 > non-HTTP-based application protocols. >=20 > Clients typically store the user's long-term credential. This does,=20 > however, lead to significant security vulnerabilities, for example,=20 > when such a credential leaks. A significant benefit of OAuth for=20 > usage in those clients is that the password is replaced by a shared=20 > secret with higher entropy, i.e., the token. Tokens typically provide=20= > limited access rights and can be managed and revoked separately from=20= > the user's long-term password. >=20 > This document is a product of the Common Authentication Technology=20 > Next Generation Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track=20= > protocol for the Internet community, and requests discussion and=20 > suggestions for improvements. Please refer to the current edition of=20= > the Official Internet Protocol Standards=20 > (https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww = . > rfc-editor.org = %2fstandards&data=3D01%7c01%7cMichael.Jones%40micr= osoft.com = %7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f= 141af91ab2d7cd011db47%7c1&sdata=3D7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5v= ijFPU%3d) for the standardization state and status of this protocol. = Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see >=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i= = = > etf.org = %2fmailman%2flistinfo%2fietf-announce&data=3D01%7c01%7cMi= chael.Jo > nes%40microsoft.com = %7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f= 14 > 1af91ab2d7cd011db47%7c1&sdata=3DaGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ5t= > WbEkg%3d=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fmailm= = = > an.rfc-editor.org = %2fmailman%2flistinfo%2frfc-dist&data=3D01%7c01= %7cMicha > el.Jones%40microsoft.com = %7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf > 86f141af91ab2d7cd011db47%7c1&sdata=3Dagec9juMh0Zzn1mrY6avpBrLPlFfCs8zsyx= > 8bSLgDdc%3d >=20 > For searching the RFC series, see=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r= = = > fc-editor.org = %2fsearch&data=3D01%7c01%7cMichael.Jones%40microsof= t.com %7c > 9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c > 1&sdata=3DveVw3wrA9Wz6CWTUfVTLCKAdduFgUDkiaabcuqFyRxc%3d > For downloading RFCs, see=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r= = = > fc-editor.org = %2frfc.html&data=3D01%7c01%7cMichael.Jones%40micros= oft.com % > 7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47% > 7c1&sdata=3D93atgoSh8enZBPOxNfMophuutPvidnrfoMxOc0XmjS8%3d >=20 > Requests for special distribution should be addressed to either the=20 > author of the RFC in question, or to rfc-editor@rfc-editor.org.=20 > Unless specifically noted otherwise on the RFC itself, all RFCs are=20 > for unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 >=20 >=20 >=20 >=20 > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i= = = > etf.org = %2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jo= nes%40mi > crosoft.com = %7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141a= f91ab2 > d7cd011db47%7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%= > 3d >=20 >=20 > OAuth mailing list > OAuth@ietf.org > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40micros= oft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011d= b47%7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%3d = >=20 >=20 > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F0265934-B26B-4E2F-99D8-CD94E5422395 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hooray, congratulations!

 =E2=80=94 Justin

On Sep 1, 2015, at 12:37 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

And thank you Hannes for all = the guidance and being a great collaborator on this!
 
And to the WG, = chairs, and shepherds, we did something good here.  Thank you all for the review, attention, time, and your help as well.
 
-bill



=
On Tuesday, = September 1, 2015 9:04 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
 =


+1

Am 1. September 2015 17:44:12 MESZ, = schrieb Mike Jones <Michael.Jones@microsoft.com>:
Congratulations, Bill!

-----Original =
Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, September 01, 2015 8:14 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: =
[OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security =
Layer (SASL) Mechanisms for OAuth

+1 !

Phil

On Aug 31, 2015, = at 23:24, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

FYI: Thanks to Bill for the = hard work!

= -------- Forwarded Message --------
= Subject: RFC 7628 on A Set of Simple Authentication and Security = Layer
(SASL) Mechanisms for OAuth
Date: Mon, 31 Aug 2015 21:56:17 -0700 = (PDT)
From: rfc-editor@rfc-editor.org
= Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: = kitten@ietf.org, drafts-update-ref@iana.org,
= rfc-editor@rfc-editor.org
=
A new Request for Comments is now = available in online RFC libraries.


RFC = 7628

= Title: A Set of Simple Authentication
= and Security Layer (SASL) Mechanisms
for OAuth
= Author: W. Mills, T. Showalter, H. Tschofenig
Status: Standards Track
Stream: IETF
= Date: August 2015
Mailbox: = wmills_92105@yahoo.com,
= tjs@psaux.com,
= Hannes.Tschofenig@gmx.net
= Pages: 21
Characters: = 46408
Updates/Obsoletes/SeeAlso: = None

= I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt

URL: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.rfc-editor.org%2finfo%2frfc7628&data=3D01%7c01%7cMichael.Jones= %40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab= 2d7cd011db47%7c1&sdata=3DJ1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3= d

= DOI: https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f= %2fdx.doi.org%2f10.17487%2fRFC7628&data=3D01%7c01%7cMichael.Jones%40mi= crosoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd= 011db47%7c1&sdata=3D%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d

OAuth = enables a third-party application to obtain limited access to a
protected resource, either on behalf of a = resource owner by
orchestrating an = approval interaction or by allowing the third-party
application to obtain access on its own behalf.

This document = defines how an application client uses credentials
obtained via OAuth over the Simple Authentication and = Security Layer
(SASL) to access a protected = resource at a resource server. Thereby,
= it enables schemes defined within the OAuth framework for
non-HTTP-based application protocols.

Clients = typically store the user's long-term credential. This does,
however, lead to significant security = vulnerabilities, for example,
when such a = credential leaks. A significant benefit of OAuth for
usage in those clients is that the password is replaced by a = shared
secret with higher entropy, i.e., = the token. Tokens typically provide
= limited access rights and can be managed and revoked separately from
the user's long-term password.

This document = is a product of the Common Authentication Technology
Next Generation Working Group of the IETF.

This is now a Proposed = Standard.

= STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and
suggestions for = improvements. Please refer to the current edition of
the Official Internet Protocol Standards
(https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.
rfc-editor.org%2fstandards&data=3D01%7c01%7cMichael.Jon= es%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988= bf86f141af91ab2d7cd011db47%7c1&sdata=3D7JPZiamj4nhqHgthEPDIzgpqkvR%2fA= A6bj4Ck5vijFPU%3d) for the standardization state and status of this = protocol. Distribution of this memo is unlimited.

This announcement is sent to = the IETF-Announce and rfc-dist lists.
To = subscribe or unsubscribe, see

https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.i
etf.org%2fmailman%2flistinfo%2fietf-announce&data=3D01%= 7c01%7cMichael.Jo
nes%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988= bf86f14
= 1af91ab2d7cd011db47%7c1&sdata=3DaGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ= 5t
WbEkg%3d
= https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fmailm
an.rfc-editor.org%2fmailman%2flistinfo%2frfc-dist&data=3D= 01%7c01%7cMicha
el.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988= bf
= 86f141af91ab2d7cd011db47%7c1&sdata=3Dagec9juMh0Zzn1mrY6avpBrLPlFfCs8zs= yx
8bSLgDdc%3d
=
For searching the RFC series, see
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.r
fc-editor.org%2fsearch&data=3D01%7c01%7cMichael.Jones%<= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" = href=3D"http://40microsoft.com/" class=3D"">40microsoft.com%7c
= 9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c
= 1&sdata=3DveVw3wrA9Wz6CWTUfVTLCKAdduFgUDkiaabcuqFyRxc%3d
For downloading RFCs, see
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.r
fc-editor.org%2frfc.html&data=3D01%7c01%7cMichael.Jones= %40microsoft.com%
= 7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%
= 7c1&sdata=3D93atgoSh8enZBPOxNfMophuutPvidnrfoMxOc0XmjS8%3d

Requests for = special distribution should be addressed to either the
author of the RFC = in question, or to rfc-editor@rfc-editor.org.
= Unless specifically noted otherwise on the RFC itself, all RFCs are
for unlimited distribution.


= The RFC Editor Team
Association Management = Solutions, LLC



=


OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.i
etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cM= ichael.Jones%40mi
crosoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86= f141af91ab2
= d7cd011db47%7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6g= U%
3d


OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael= .Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141= af91ab2d7cd011db47%7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2f= Tn%2b6gU%3d


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

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


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

= --Apple-Mail=_F0265934-B26B-4E2F-99D8-CD94E5422395-- From nobody Wed Sep 2 07:30:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E5D1B5EC7 for ; Tue, 1 Sep 2015 08:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14hReRNZXqkm for ; Tue, 1 Sep 2015 08:50:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64601B4EB5 for ; Tue, 1 Sep 2015 08:50:08 -0700 (PDT) Received: from BLUPR03MB407.namprd03.prod.outlook.com (10.141.78.24) by BLUPR03MB439.namprd03.prod.outlook.com (10.141.78.151) with Microsoft SMTP Server (TLS) id 15.1.262.15; Tue, 1 Sep 2015 15:50:05 +0000 Received: from BLUPR03MB407.namprd03.prod.outlook.com ([10.141.78.24]) by BLUPR03MB407.namprd03.prod.outlook.com ([10.141.78.24]) with mapi id 15.01.0256.013; Tue, 1 Sep 2015 15:50:05 +0000 From: Bill Mills To: Mike Jones , Phil Hunt , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth Thread-Index: AQHQ5Ir75W0PLpZNOkaEhwVtHuhg4J4nyH8AgAAH7bCAAAF5cA== Date: Tue, 1 Sep 2015 15:50:05 +0000 Message-ID: References: <20150901045617.CB44D187A98@rfc-editor.org> <55E544A6.3050203@gmx.net> <514ABD00-586C-4ABC-A867-698CBC50DA79@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wimills@microsoft.com; x-originating-ip: [2602:306:31fd:42a0:cdcd:5e19:7cdb:9355] x-microsoft-exchange-diagnostics: 1; BLUPR03MB439; 5:p/hCras9xR9Hg4u+nrqhfNWFVI1qOaRMFm/UvPQtjTs4c6RsFix3JZiocRu3MBee2hxxLaKApxnoGgoAobLOXMI7BkEhnT+ZCaoWy4G4UOPnj5CWslXUlBIjUKwPqOmRz0sBFZCU7xkC7R/6qSiCtQ==; 24:IS1FWJB2Dr/Ib3gKGE72lRVD5M6UMGyTKeVIxJuxfzieZhXJPk++/vn92eIZiTveHNOdz5UauvpeXSI5vKGbBwkCq6qBV4/Xc1LCJ6BHgxc=; 20:8CEnG1bhPl0USV1t6Lh29B6i5Q5IsUBs6nbeOFDMwm0RYLf/vLRC7LUUUaGY/F3ut5cyQyNfv8WDfee6bIdVhg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:BLUPR03MB439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BLUPR03MB439; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB439; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(15594002)(377454003)(13464003)(69234005)(199003)(24454002)(2473001)(4001540100001)(64706001)(81156007)(97736004)(2900100001)(5004730100002)(2950100001)(5007970100001)(5880100001)(5001860100001)(77156002)(62966003)(5001830100001)(2421001)(68736005)(92566002)(5003600100002)(46102003)(1511001)(5001770100001)(77096005)(102836002)(15975445007)(5005710100001)(10400500002)(10290500002)(76576001)(8990500004)(10090500001)(106116001)(106356001)(105586002)(99286002)(86362001)(575784001)(87936001)(86612001)(76176999)(50986999)(54356999)(19580395003)(74316001)(19580405001)(33656002)(101416001)(40100003)(5001960100002)(2561002)(551544002)(5002640100001)(122556002)(93886004)(2656002)(189998001)(24704002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB439; H:BLUPR03MB407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2015 15:50:05.4097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB439 Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 07:30:14 -0700 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 15:50:11 -0000 And thank you Hannes for all the guidance and being a great collaborator on= this! And to the WG, chairs, and shepherds, we did something good here. Thank yo= u all for the review, attention, time, and your help as well. -bill -----Original Message----- From: Mike Jones=20 Sent: Tuesday, September 1, 2015 8:44 AM To: Bill Mills ; Phil Hunt ; H= annes Tschofenig Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and= Security Layer (SASL) Mechanisms for OAuth Congratulations, Bill! -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, September 01, 2015 8:14 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and= Security Layer (SASL) Mechanisms for OAuth +1 ! Phil > On Aug 31, 2015, at 23:24, Hannes Tschofenig = wrote: >=20 > FYI: Thanks to Bill for the hard work! >=20 > -------- Forwarded Message -------- > Subject: RFC 7628 on A Set of Simple Authentication and Security Layer > (SASL) Mechanisms for OAuth > Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT) > From: rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > CC: kitten@ietf.org, drafts-update-ref@iana.org,=20 > rfc-editor@rfc-editor.org >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7628 >=20 > Title: A Set of Simple Authentication > and Security Layer (SASL) Mechanisms > for OAuth > Author: W. Mills, T. Showalter, H. Tschofenig > Status: Standards Track > Stream: IETF > Date: August 2015 > Mailbox: wmills_92105@yahoo.com, > tjs@psaux.com, > Hannes.Tschofenig@gmx.net > Pages: 21 > Characters: 46408 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt >=20 > URL: https://na01.safelinks.protection.outlook.com/?url=3Dh= ttps%3a%2f%2fwww.rfc-editor.org%2finfo%2frfc7628&data=3D01%7c01%7cMichael.J= ones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af9= 1ab2d7cd011db47%7c1&sdata=3DJ1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d >=20 > DOI: https://na01.safelinks.protection.outlook.com/?url=3Dh= ttp%3a%2f%2fdx.doi.org%2f10.17487%2fRFC7628&data=3D01%7c01%7cMichael.Jones%= 40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d= 7cd011db47%7c1&sdata=3D%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d >=20 > OAuth enables a third-party application to obtain limited access to a=20 > protected resource, either on behalf of a resource owner by=20 > orchestrating an approval interaction or by allowing the third-party=20 > application to obtain access on its own behalf. >=20 > This document defines how an application client uses credentials=20 > obtained via OAuth over the Simple Authentication and Security Layer > (SASL) to access a protected resource at a resource server. Thereby,=20 > it enables schemes defined within the OAuth framework for=20 > non-HTTP-based application protocols. >=20 > Clients typically store the user's long-term credential. This does,=20 > however, lead to significant security vulnerabilities, for example,=20 > when such a credential leaks. A significant benefit of OAuth for=20 > usage in those clients is that the password is replaced by a shared=20 > secret with higher entropy, i.e., the token. Tokens typically provide=20 > limited access rights and can be managed and revoked separately from=20 > the user's long-term password. >=20 > This document is a product of the Common Authentication Technology=20 > Next Generation Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track=20 > protocol for the Internet community, and requests discussion and=20 > suggestions for improvements. Please refer to the current edition of=20 > the Official Internet Protocol Standards=20 > (https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. > rfc-editor.org%2fstandards&data=3D01%7c01%7cMichael.Jones%40microsoft.com= %7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&= sdata=3D7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5vijFPU%3d) for the standardi= zation state and status of this protocol. Distribution of this memo is unl= imited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > =20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2fietf-announce&data=3D01%7c01%7cMichael.Jo > nes%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f14 > 1af91ab2d7cd011db47%7c1&sdata=3DaGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ5t > WbEkg%3d > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fmailm > an.rfc-editor.org%2fmailman%2flistinfo%2frfc-dist&data=3D01%7c01%7cMicha > el.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf > 86f141af91ab2d7cd011db47%7c1&sdata=3Dagec9juMh0Zzn1mrY6avpBrLPlFfCs8zsyx > 8bSLgDdc%3d >=20 > For searching the RFC series, see > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r > fc-editor.org%2fsearch&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c > 9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c > 1&sdata=3DveVw3wrA9Wz6CWTUfVTLCKAdduFgUDkiaabcuqFyRxc%3d > For downloading RFCs, see > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.r > fc-editor.org%2frfc.html&data=3D01%7c01%7cMichael.Jones%40microsoft.com% > 7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47% > 7c1&sdata=3D93atgoSh8enZBPOxNfMophuutPvidnrfoMxOc0XmjS8%3d >=20 > Requests for special distribution should be addressed to either the=20 > author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless specifically noted otherwise on the RFC itself, all RFCs are=20 > for unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40mi > crosoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2 > d7cd011db47%7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU% > 3d _______________________________________________ OAuth mailing list OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cMichael.Jones%40microsof= t.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47= %7c1&sdata=3DILpgvSqnqwWhHs7BAm7xXpjoUdVRhJhB2G3m%2fTn%2b6gU%3d From nobody Tue Sep 15 11:10:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027831A8A52 for ; Tue, 15 Sep 2015 11:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx1XOpx66fzr for ; Tue, 15 Sep 2015 11:10:01 -0700 (PDT) Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED311A8A77 for ; Tue, 15 Sep 2015 11:10:01 -0700 (PDT) Received: from mtaout-aan02.mx.aol.com (mtaout-aan02.mx.aol.com [172.27.19.78]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 4507C3800050; Tue, 15 Sep 2015 14:10:00 -0400 (EDT) Received: from [10.172.164.44] (unknown [10.172.164.44]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aan02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 824163800008D; Tue, 15 Sep 2015 14:09:59 -0400 (EDT) To: "oauth@ietf.org" From: George Fletcher Organization: AOL LLC Message-ID: <55F85EF5.5080609@aol.com> Date: Tue, 15 Sep 2015 14:09:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090203060506080106070004" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1442340600; bh=LEl6bt6YJk+Irt8gvYhxQyoZJtMAGdR2iOE44rgKESE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=w722fxOstxtDnXVt34NHM3jnfyXxmhPt36rGocHKGnICGC8KpUxPKghEhcvWpmxuO YZyL/RgSOwiPs7tLGZEuD8IFyNEopqhVP3a4li+KQZxRhIdJ5JOW/+UPlIE2tFuck9 5hBPR9ChBG/5v0KwXzhsWLEFlnEHkedZGAg95LzQ= x-aol-sid: 3039ac1b134e55f85ef70060 X-AOL-IP: 10.172.164.44 Archived-At: Subject: [OAUTH-WG] OAuth2 2 legged flows with JWT client assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 18:10:03 -0000 This is a multi-part message in MIME format. --------------090203060506080106070004 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I just want to verify my reading of RFC 7523[1] for the use case where a client wants to get an access token for itself to use as authorization for future API calls. This is effectively exchanging a JWS for a "short lived" access token. My understanding of section 2.2 of RFC 7523, is that the 'client_assertion_type' and 'client_assertion' replace the default [OAuth2 (RFC 6749)] client authentication mechanism of client_id and client_secret. Therefore the correct way to implement this 2 legged flow is to use the OAuth2 (RFC 6749) client_credentials grant_type (Section 4.4) with the JWT Bearer defined client_assertion_type and client_assertion. This would look something like (line breaks added for readability) POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=client_credentials& client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer& client_assertion=& scope="myscopes" Is there a different industry standard for this use case? I'm checking as I find that multiple AS implementations do this differently:) Thanks, George [1] https://tools.ietf.org/html/rfc7523 --------------090203060506080106070004 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I just want to verify my reading of RFC 7523[1] for the use case where a client wants to get an access token for itself to use as authorization for future API calls. This is effectively exchanging a JWS for a "short lived" access token.

My understanding of section 2.2 of RFC 7523, is that the 'client_assertion_type' and 'client_assertion' replace the default [OAuth2 (RFC 6749)] client authentication mechanism of client_id and client_secret.

Therefore the correct way to implement this 2 legged flow is to use the OAuth2 (RFC 6749) client_credentials grant_type (Section 4.4) with the JWT Bearer defined client_assertion_type and client_assertion.

This would look something like (line breaks added for readability)

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
client_assertion=<encoded JWS>&
scope="myscopes"
Is there a different industry standard for this use case? I'm checking as I find that multiple AS implementations do this differently:)

Thanks,
George
[1] https://tools.ietf.org/html/rfc7523
--------------090203060506080106070004-- From nobody Tue Sep 15 13:42:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1720B1AD0A0 for ; Tue, 15 Sep 2015 13:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNyotBCryTXG for ; Tue, 15 Sep 2015 13:42:02 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB371AD09D for ; Tue, 15 Sep 2015 13:42:02 -0700 (PDT) X-AuditID: 1209190e-f79296d00000051c-4b-55f882991d0f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 69.88.01308.99288F55; Tue, 15 Sep 2015 16:42:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t8FKg0Cl021757; Tue, 15 Sep 2015 16:42:00 -0400 Received: from [10.10.49.130] (173-14-170-177-NewEngland.hfc.comcastbusiness.net [173.14.170.177]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t8FKfxWP016248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Sep 2015 16:42:00 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_4CFB6390-47C1-4DC9-A8E0-86996EF2A2DC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <55F85EF5.5080609@aol.com> Date: Tue, 15 Sep 2015 16:41:58 -0400 Message-Id: <15EEB79E-5003-4CC1-892D-96357CB0B89B@mit.edu> References: <55F85EF5.5080609@aol.com> To: George Fletcher X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6nrjuz6UeowYr3whZ3ulawW5x8+4rN gcnj/u6V7B5LlvxkCmCK4rJJSc3JLEst0rdL4MrYMWcNc8EW64oDPbdYGhjXG3YxcnBICJhI fOuQ6GLkBDLFJC7cW8/WxcjFISSwmElizrOXLBDORkaJFc8+MkI495kkfnasZgVpYRZIkHjy dQ0biM0roCfx6tZlsLiwgIfE7m3rmEBsNgFVielrWsBsTgF1iY53nWA1LEDxRYfus4BcwQwU bz/pAjHGSuJA50uwciEBNYlttx6BjRcBsptWrmGEuFRWYvfvR0wTGAVmIbliFpIrIOLaEssW vmaGsDUl9ncvZ8EU15Do/DaRdQEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTS TYygcOeU5NvB+PWg0iFGAQ5GJR7eDZ3fQ4VYE8uKK3MPMUpyMCmJ8m6q/REqxJeUn1KZkVic EV9UmpNafIhRgoNZSYR3Yw1QjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaG g0NJgjegEahRsCg1PbUiLTOnBCHNxMEJMpwHaHgHSA1vcUFibnFmOkT+FKMux751d9YyCbHk 5eelSonzxoEUCYAUZZTmwc0Bpam1fKs2vmIUB3pLmHcBSBUPMMXBTXoFtIQJaIl76jeQJSWJ CCmpBsaiv8Gchidnc3HdP1Tw+6qOy21j85vHJavssv5t37PxyPWNM/60ZvHMObTjZ3FbhUuF yXa/zR+tW+TvVd1nvi+lXzXxjOlsk/1B93PyS2bHTnG7Eja5bs6V/0L76g75e9m3bspWbjZS nVvTW6S9bU7Q7xYRjvQ3GnU8kTYC377OsLC2WqobaaPEUpyRaKjFXFScCACCYaTQLgMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth2 2 legged flows with JWT client assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 20:42:05 -0000 --Apple-Mail=_4CFB6390-47C1-4DC9-A8E0-86996EF2A2DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s how we=E2=80=99ve implemented it, but I=E2=80=99ve seen = others pass the JWS for the token directly using the assertion grant = type. Personally I find that a little confusing, since it=E2=80=99s = still the client making the swap, but maybe there=E2=80=99s something = useful there anyway. It honestly feels a bit too much like WS-*, and one = can hope that we=E2=80=99ve learned from the mistakes of the past by = now. I think the difference may be who makes the JWS. If the client is making = the JWS and using it to swap for a new token, then that=E2=80=99s a case = for using client credentials and authenticating using the JWS. If the = JWS is coming from a third party and being handed to the client, and the = client=E2=80=99s using that as-is to swap for a new token, then that=E2=80= =99s a case of using the JWS as an assertion directly to the AS and = getting a token there.=20 But I agree that it=E2=80=99s confusing that there are two similar = mechanisms here. =E2=80=94 Justin > On Sep 15, 2015, at 2:09 PM, George Fletcher wrote: >=20 > Hi, >=20 > I just want to verify my reading of RFC 7523[1] for the use case where = a client wants to get an access token for itself to use as authorization = for future API calls. This is effectively exchanging a JWS for a "short = lived" access token. >=20 > My understanding of section 2.2 of RFC 7523, is that the = 'client_assertion_type' and 'client_assertion' replace the default = [OAuth2 (RFC 6749)] client authentication mechanism of client_id and = client_secret. >=20 > Therefore the correct way to implement this 2 legged flow is to use = the OAuth2 (RFC 6749) client_credentials grant_type (Section 4.4) with = the JWT Bearer defined client_assertion_type and client_assertion. >=20 > This would look something like (line breaks added for readability) >=20 > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded >=20 > grant_type=3Dclient_credentials& > = client_assertion_type=3Durn:ietf:params:oauth:client-assertion-type:jwt-be= arer& > client_assertion=3D& > scope=3D"myscopes" > Is there a different industry standard for this use case? I'm checking = as I find that multiple AS implementations do this differently:) >=20 > Thanks, > George > [1] https://tools.ietf.org/html/rfc7523 = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4CFB6390-47C1-4DC9-A8E0-86996EF2A2DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s how we=E2=80=99ve implemented it, but I=E2=80=99= ve seen others pass the JWS for the token directly using the assertion = grant type. Personally I find that a little confusing, since it=E2=80=99s = still the client making the swap, but maybe there=E2=80=99s something = useful there anyway. It honestly feels a bit too much like WS-*, and one = can hope that we=E2=80=99ve learned from the mistakes of the past by = now.

I think the = difference may be who makes the JWS. If the client is making the JWS and = using it to swap for a new token, then that=E2=80=99s a case for using = client credentials and authenticating using the JWS. If the JWS is = coming from a third party and being handed to the client, and the = client=E2=80=99s using that as-is to swap for a new token, then that=E2=80= =99s a case of using the JWS as an assertion directly to the AS and = getting a token there. 

But I agree that it=E2=80=99s confusing = that there are two similar mechanisms here.

 =E2=80=94 Justin

On Sep 15, 2015, at 2:09 PM, George Fletcher <gffletch@aol.com> = wrote:

=20
Hi,

I just want to verify my reading of RFC 7523[1] for the use case where a client wants to get an access token for itself to use as authorization for future API calls. This is effectively exchanging a JWS for a "short lived" access token.

My understanding of section 2.2 of RFC 7523, is that the 'client_assertion_type' and 'client_assertion' replace the default [OAuth2 (RFC 6749)] client authentication mechanism of client_id and client_secret.

Therefore the correct way to implement this 2 legged flow is to use the OAuth2 (RFC 6749) client_credentials grant_type (Section 4.4) with the JWT Bearer defined client_assertion_type and client_assertion.

This would look something like (line breaks added for readability)

POST /token HTTP/1.1
Host: server.example.com
Content-Type: = application/x-www-form-urlencoded

grant_type=3Dclient_credentials&
client_assertion_type=3Durn:ietf:params:oauth:client-assertion-= type:jwt-bearer&
client_assertion=3D<encoded = JWS>&
scope=3D"myscopes"
=20 
Is there a different industry standard for =
this use case? I'm checking as I find that multiple AS implementations =
do this differently:)

Thanks,
George
[1] https://tools.ietf.org/html/r= fc7523
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_4CFB6390-47C1-4DC9-A8E0-86996EF2A2DC-- From nobody Wed Sep 16 09:28:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FB81B350C for ; Wed, 16 Sep 2015 09:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8H1nbvxdGNz for ; Wed, 16 Sep 2015 09:28:02 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF671B34CB for ; Wed, 16 Sep 2015 09:28:02 -0700 (PDT) Received: by qgt47 with SMTP id 47so175805614qgt.2 for ; Wed, 16 Sep 2015 09:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GL2P67RXgiaTGN3xbP0qe6Ng4UjL4vXCaIcOk7BytBk=; b=GEJX6XfOeY4WjKuldly++tiFb07UzusHofcKPFzHaxq6m3eFbE+dDQZB6VskG6E0Jv 3BUt9CjNGRUwhmsIn2JAmIYMSxyORIAuFBKiJEJXzBCmEsIDI41kaZITGDFOvclWfb8l R7TnRyX3aWXWVY1pf8U6yeH1Z/rdHt9ppZxVU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GL2P67RXgiaTGN3xbP0qe6Ng4UjL4vXCaIcOk7BytBk=; b=YIm84hXbAB0q62QyiJ6zOsKn/fd7OjfMg6Vw/7KHKAQkzn/11seGSzlLq4vPEBgjeG AmNCGJni2Wkdv7QVoAiQ0Emvu14RFa6ZvreaZXpqvrBknP+RRqhbdmDa+/JwX+hBWg3A +RcPwrU+hjnml28h8S2TysOkNTWxEGwqinTHe6LW+MFmHgM0Ab3LbhkLidvwL9FtVwQS ztwMbQURo409C30M9PSu/UekhvuLvYBi695c3fr+8VKQIA28jzQAoyhbgpjgbvD0Gk+X nRTtmtsjDQ9sC55NK3YhccvDWi3VBbiwGtqAej89OREUg69Ld3VNNk9B2qTgrhQGyMDK Ys6g== X-Gm-Message-State: ALoCoQkr4etqQC4Tn5qL/t9xSsoLRBL96J0etd5JCWS/hNDpRMV+XRMcnLLgfu97HYEKLtSu4dF6 X-Received: by 10.140.231.76 with SMTP id b73mr9937427qhc.87.1442420881402; Wed, 16 Sep 2015 09:28:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.227 with HTTP; Wed, 16 Sep 2015 09:27:31 -0700 (PDT) In-Reply-To: <15EEB79E-5003-4CC1-892D-96357CB0B89B@mit.edu> References: <55F85EF5.5080609@aol.com> <15EEB79E-5003-4CC1-892D-96357CB0B89B@mit.edu> From: Brian Campbell Date: Wed, 16 Sep 2015 10:27:31 -0600 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c130ee40dafc051fdfc858 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth2 2 legged flows with JWT client assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:28:05 -0000 --001a11c130ee40dafc051fdfc858 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, when a client wants to get an access token for itself, the client_credentials grant_type with client_assertion_type/client_assertion. We attempted to call this out in the assertion framework (RFC 7521) in a discussion of "Common Scenarios " with the section "Client Acting on Behalf of Itself = " but, despite good intentions, inheritance in specs is often overlooked. When a client is accessing resources on behalf of itself, it does so in a manner analogous to the Client Credentials Grant defined in Section 4.4 of OAuth 2.0 [RFC6749 ]. This is a special case that combines both the authentication and authorization grant usage patterns. In this case, the interactions with the authorization server should be treated as using an assertion for Client Authentication according to Section 4.2 , while using the "grant_type" parameter with the value "client_credentials" to indicate that the client is requesting an access token using only its client credentials. The following example demonstrates an assertion being used for a client credentials access token request, as defined in Section 4.4.2 of OAuth 2.0 [RFC6749 ] (with extra line breaks for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dclient_credentials& client_assertion_type=3Durn%3Aietf%3Aparams%3Aoauth %3Aclient-assertion-type%3Asaml2-bearer& client_assertion=3DPHNhbW...[omitted for brevity]...ZT On Tue, Sep 15, 2015 at 2:41 PM, Justin Richer wrote: > That=E2=80=99s how we=E2=80=99ve implemented it, but I=E2=80=99ve seen ot= hers pass the JWS for the > token directly using the assertion grant type. Personally I find that a > little confusing, since it=E2=80=99s still the client making the swap, bu= t maybe > there=E2=80=99s something useful there anyway. It honestly feels a bit to= o much > like WS-*, and one can hope that we=E2=80=99ve learned from the mistakes = of the > past by now. > > I think the difference may be who makes the JWS. If the client is making > the JWS and using it to swap for a new token, then that=E2=80=99s a case = for using > client credentials and authenticating using the JWS. If the JWS is coming > from a third party and being handed to the client, and the client=E2=80= =99s using > that as-is to swap for a new token, then that=E2=80=99s a case of using t= he JWS as > an assertion directly to the AS and getting a token there. > > But I agree that it=E2=80=99s confusing that there are two similar mechan= isms here. > > =E2=80=94 Justin > > On Sep 15, 2015, at 2:09 PM, George Fletcher wrote: > > Hi, > > I just want to verify my reading of RFC 7523[1] for the use case where a > client wants to get an access token for itself to use as authorization fo= r > future API calls. This is effectively exchanging a JWS for a "short lived= " > access token. > > My understanding of section 2.2 of RFC 7523, is that the > 'client_assertion_type' and 'client_assertion' replace the default [OAuth= 2 > (RFC 6749)] client authentication mechanism of client_id and client_secre= t. > > Therefore the correct way to implement this 2 legged flow is to use the > OAuth2 (RFC 6749) client_credentials grant_type (Section 4.4) with the JW= T > Bearer defined client_assertion_type and client_assertion. > > This would look something like (line breaks added for readability) > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=3Dclient_credentials& > > client_assertion_type=3Durn:ietf:params:oauth:client-assertion-type:jwt-b= earer& > client_assertion=3D& > scope=3D"myscopes" > > Is there a different industry standard for this use case? I'm checking as= I find that multiple AS implementations do this differently:) > > Thanks, > George > > [1] https://tools.ietf.org/html/rfc7523 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c130ee40dafc051fdfc858 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, when We attempted to call this out= in the assertion framework (RFC 7521) in a discussion of "Common Scenarios" wi= th the section "Client Acting on Behalf of Itself" but, despite good intentio= ns, inheritance in specs is often overlooked. 

   When a client is accessing resources on behalf of itself, it does so
   in a manner analogous to the Client Credentials Grant defined in
   Section 4.4 of OAuth 2.0 [RFC6749].  This is a s=
pecial case that
   combines both the authentication and authorization grant usage
   patterns.  In this case, the interactions with the authorization
   server should be treated as using an assertion for Client
   Authentication according to Section 4.2, while using the "grant_type"
   parameter with the value "client_credentials" to indicate that=
 the
   client is requesting an access token using only its client
   credentials.

   The following example demonstrates an assertion being used for a
   client credentials access token request, as defined in Section 4.4.2
   of OAuth 2.0 [RFC6749] (with extra l=
ine breaks for display purposes
   only):

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=3Dclient_credentials&
     client_assertion_type=3Durn%3Aietf%3Aparams%3Aoauth
     %3Aclient-assertion-type%3Asaml2-bearer&
     client_assertion=3DPHNhbW...[omitted for brevity]...ZT

On Tue, Sep 15, 2015 = at 2:41 PM, Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s h= ow we=E2=80=99ve implemented it, but I=E2=80=99ve seen others pass the JWS = for the token directly using the assertion grant type. Personally I find th= at a little confusing, since it=E2=80=99s still the client making the swap,= but maybe there=E2=80=99s something useful there anyway. It honestly feels= a bit too much like WS-*, and one can hope that we=E2=80=99ve learned from= the mistakes of the past by now.

I think the difference= may be who makes the JWS. If the client is making the JWS and using it to = swap for a new token, then that=E2=80=99s a case for using client credentia= ls and authenticating using the JWS. If the JWS is coming from a third part= y and being handed to the client, and the client=E2=80=99s using that as-is= to swap for a new token, then that=E2=80=99s a case of using the JWS as an= assertion directly to the AS and getting a token there.=C2=A0
But I agree that it=E2=80=99s confusing that there are two sim= ilar mechanisms here.

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

On Sep = 15, 2015, at 2:09 PM, George Fletcher <gffletch@aol.com> wrote:

<= div>
=20
Hi,

I just want to verify my reading of RFC 7523[1] for the use case where a client wants to get an access token for itself to use as authorization for future API calls. This is effectively exchanging a JWS for a "short lived" access token.

My understanding of section 2.2 of RFC 7523, is that the 'client_assertion_type' and 'client_assertion' repl= ace the default [OAuth2 (RFC 6749)] client authentication mechanism of client_id and client_secret.

Therefore the correct way to implement this 2 legged flow is to use the OAuth2 (RFC 6749) client_credentials grant_type (Section 4.4) with the JWT Bearer defined client_assertion_type and client_assertion.

This would look something like (line breaks added for readability)

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=3Dclient_credentials&
client_assertion_type=3Durn:ietf:params:oauth:client-asserti= on-type:jwt-bearer&
client_assertion=3D<encoded JWS>&
scope=3D"myscopes"
=20 
Is there a diff=
erent industry standard for this use case? I'm checking as I find that =
multiple AS implementations do this differently:)

Thanks,
George
[1] https://tools.ietf.org/html/rfc7523
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

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


--001a11c130ee40dafc051fdfc858-- From nobody Wed Sep 16 13:33:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9FF1A1A4A for ; Wed, 16 Sep 2015 13:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV6m5UGaq_NK for ; Wed, 16 Sep 2015 13:33:09 -0700 (PDT) Received: from omr-a011e.mx.aol.com (omr-a011e.mx.aol.com [204.29.186.59]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BBA1A1A39 for ; Wed, 16 Sep 2015 13:33:09 -0700 (PDT) Received: from mtaout-mbb01.mx.aol.com (mtaout-mbb01.mx.aol.com [172.26.254.109]) by omr-a011e.mx.aol.com (Outbound Mail Relay) with ESMTP id 2BCD538000AA; Wed, 16 Sep 2015 16:33:08 -0400 (EDT) Received: from [10.172.96.190] (unknown [10.172.96.190]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mbb01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 254BD3800008E; Wed, 16 Sep 2015 16:33:07 -0400 (EDT) To: Brian Campbell , Justin Richer References: <55F85EF5.5080609@aol.com> <15EEB79E-5003-4CC1-892D-96357CB0B89B@mit.edu> From: George Fletcher Organization: AOL LLC Message-ID: <55F9D202.2070305@aol.com> Date: Wed, 16 Sep 2015 16:33:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050203050201070902020808" x-aol-global-disposition: G X-AOL-VSS-INFO: 5700.7163/105960 X-AOL-VSS-CODE: clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1442435588; bh=Qae4e5TxJc6UvwYxf916rFtLpFpSWzQQKcpEvSeZ3Vw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=mAA86YKYqacpzuWzkvETvI9QmAEvpRRq40iu0p05Qk/nY8v25qC3OTUAzTeB1QIqZ CceaBTScdvDzLo+Wx61P4IDQ7X253cS4rLGaIIOOG1anmguPDkkXSonSzb3h3DbSaZ ieeRD//knKj26/C28+ZA5vcJ+bJ0swjoEyi2DVMM= x-aol-sid: 3039ac1afe6d55f9d2035608 X-AOL-IP: 10.172.96.190 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth2 2 legged flows with JWT client assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 20:33:12 -0000 This is a multi-part message in MIME format. --------------050203050201070902020808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the pointer Brian, that's helpful! (and yes I didn't dig through the framework spec:) On 9/16/15 12:27 PM, Brian Campbell wrote: > Yeah, when a client wants to get an access token for itself, the > client_credentials grant_type with > client_assertion_type/client_assertion. > > We attempted to call this out in the assertion framework (RFC 7521) in > a discussion of "Common Scenarios > " with the section > "Client Acting on Behalf of Itself > " but, despite good > intentions, inheritance in specs is often overlooked. > > When a client is accessing resources on behalf of itself, it does so > in a manner analogous to the Client Credentials Grant defined in > Section 4.4 of OAuth 2.0 [RFC6749 ]. This is a special case that > combines both the authentication and authorization grant usage > patterns. In this case, the interactions with the authorization > server should be treated as using an assertion for Client > Authentication according toSection 4.2 , while using the "grant_type" > parameter with the value "client_credentials" to indicate that the > client is requesting an access token using only its client > credentials. > > The following example demonstrates an assertion being used for a > client credentials access token request, as defined inSection 4.4.2 > of OAuth 2.0 [RFC6749 ] (with extra line breaks for display purposes > only): > > POST /token HTTP/1.1 > Host:server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=client_credentials& > client_assertion_type=urn%3Aietf%3Aparams%3Aoauth > %3Aclient-assertion-type%3Asaml2-bearer& > client_assertion=PHNhbW...[omitted for brevity]...ZT > > On Tue, Sep 15, 2015 at 2:41 PM, Justin Richer > wrote: > > That’s how we’ve implemented it, but I’ve seen others pass the JWS > for the token directly using the assertion grant type. Personally > I find that a little confusing, since it’s still the client making > the swap, but maybe there’s something useful there anyway. It > honestly feels a bit too much like WS-*, and one can hope that > we’ve learned from the mistakes of the past by now. > > I think the difference may be who makes the JWS. If the client is > making the JWS and using it to swap for a new token, then that’s a > case for using client credentials and authenticating using the > JWS. If the JWS is coming from a third party and being handed to > the client, and the client’s using that as-is to swap for a new > token, then that’s a case of using the JWS as an assertion > directly to the AS and getting a token there. > > But I agree that it’s confusing that there are two similar > mechanisms here. > > — Justin > >> On Sep 15, 2015, at 2:09 PM, George Fletcher > > wrote: >> >> Hi, >> >> I just want to verify my reading of RFC 7523[1] for the use case >> where a client wants to get an access token for itself to use as >> authorization for future API calls. This is effectively >> exchanging a JWS for a "short lived" access token. >> >> My understanding of section 2.2 of RFC 7523, is that the >> 'client_assertion_type' and 'client_assertion' replace the >> default [OAuth2 (RFC 6749)] client authentication mechanism of >> client_id and client_secret. >> >> Therefore the correct way to implement this 2 legged flow is to >> use the OAuth2 (RFC 6749) client_credentials grant_type (Section >> 4.4) with the JWT Bearer defined client_assertion_type and >> client_assertion. >> >> This would look something like (line breaks added for readability) >> >> POST /token HTTP/1.1 >> Host: server.example.com >> Content-Type: application/x-www-form-urlencoded >> >> grant_type=client_credentials& >> client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer& >> client_assertion=& >> scope="myscopes" >> Is there a different industry standard for this use case? I'm >> checking as I find that multiple AS implementations do this >> differently:) Thanks, George >> [1] https://tools.ietf.org/html/rfc7523 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- George Fletcher --------------050203050201070902020808 Content-Type: multipart/related; boundary="------------010609050500020105050201" --------------010609050500020105050201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks for the pointer Brian, that's helpful! (and yes I didn't dig through the framework spec:)

On 9/16/15 12:27 PM, Brian Campbell wrote:
Yeah, when a client wants to get an access token for itself, the client_credentials grant_type with client_assertion_type/client_assertion.

We attempted to call this out in the assertion framework (RFC 7521) in a discussion of "Common Scenarios" with the section "Client Acting on Behalf of Itself" but, despite good intentions, inheritance in specs is often overlooked. 

   When a client is accessing resources on behalf of itself, it does so
   in a manner analogous to the Client Credentials Grant defined in
   Section 4.4 of OAuth 2.0 [RFC6749].  This is a special case that
   combines both the authentication and authorization grant usage
   patterns.  In this case, the interactions with the authorization
   server should be treated as using an assertion for Client
   Authentication according to Section 4.2, while using the "grant_type"
   parameter with the value "client_credentials" to indicate that the
   client is requesting an access token using only its client
   credentials.

   The following example demonstrates an assertion being used for a
   client credentials access token request, as defined in Section 4.4.2
   of OAuth 2.0 [RFC6749] (with extra line breaks for display purposes
   only):

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=client_credentials&
     client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
     %3Aclient-assertion-type%3Asaml2-bearer&
     client_assertion=PHNhbW...[omitted for brevity]...ZT

On Tue, Sep 15, 2015 at 2:41 PM, Justin Richer <jricher@mit.edu> wrote:
That’s how we’ve implemented it, but I’ve seen others pass the JWS for the token directly using the assertion grant type. Personally I find that a little confusing, since it’s still the client making the swap, but maybe there’s something useful there anyway. It honestly feels a bit too much like WS-*, and one can hope that we’ve learned from the mistakes of the past by now.

I think the difference may be who makes the JWS. If the client is making the JWS and using it to swap for a new token, then that’s a case for using client credentials and authenticating using the JWS. If the JWS is coming from a third party and being handed to the client, and the client’s using that as-is to swap for a new token, then that’s a case of using the JWS as an assertion directly to the AS and getting a token there. 

But I agree that it’s confusing that there are two similar mechanisms here.

 — Justin

On Sep 15, 2015, at 2:09 PM, George Fletcher <gffletch@aol.com> wrote:

Hi,

I just want to verify my reading of RFC 7523[1] for the use case where a client wants to get an access token for itself to use as authorization for future API calls. This is effectively exchanging a JWS for a "short lived" access token.

My understanding of section 2.2 of RFC 7523, is that the 'client_assertion_type' and 'client_assertion' replace the default [OAuth2 (RFC 6749)] client authentication mechanism of client_id and client_secret.

Therefore the correct way to implement this 2 legged flow is to use the OAuth2 (RFC 6749) client_credentials grant_type (Section 4.4) with the JWT Bearer defined client_assertion_type and client_assertion.

This would look something like (line breaks added for readability)

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
client_assertion=<encoded JWS>&
scope="myscopes"
Is there a different industry standard for this use case? I'm checking as I find that multiple AS implementations do this differently:)

Thanks,
George
[1] https://tools.ietf.org/html/rfc7523
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


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



--
George Fletcher
--------------010609050500020105050201 Content-Type: text/html; charset=utf-8; name="XeC" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="XeC" Content-Base: "https://d2vm7miu7c0y35.cloudfront.net/ embed/card/XeC?scores=1&13554124169 35" Content-Location: "https://d2vm7miu7c0y35.cloudfront.net/ embed/card/XeC?scores=1&13554124169 35" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxIVE1M PjxIRUFEPjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPgo8VElUTEU+RVJST1I6IFRoZSByZXF1ZXN0IGNv dWxkIG5vdCBiZSBzYXRpc2ZpZWQ8L1RJVExFPgo8L0hFQUQ+PEJPRFk+CjxIMT5FUlJPUjwv SDE+CjxIMj5UaGUgcmVxdWVzdCBjb3VsZCBub3QgYmUgc2F0aXNmaWVkLjwvSDI+CjxIUiBu b3NoYWRlIHNpemU9IjFweCI+CkNsb3VkRnJvbnQgYXR0ZW1wdGVkIHRvIGVzdGFibGlzaCBh IGNvbm5lY3Rpb24gd2l0aCB0aGUgb3JpZ2luLCBidXQgZWl0aGVyIHRoZSBhdHRlbXB0IGZh aWxlZCBvciB0aGUgb3JpZ2luIGNsb3NlZCB0aGUgY29ubmVjdGlvbi4KPEJSIGNsZWFyPSJh bGwiPgo8SFIgbm9zaGFkZSBzaXplPSIxcHgiPgo8UFJFPgpHZW5lcmF0ZWQgYnkgY2xvdWRm cm9udCAoQ2xvdWRGcm9udCkKUmVxdWVzdCBJRDogMS1GWlhQeTkwdEltYnpqelFScjhUd0pC Ynl0Tk5oZVBYbFdnekVrUDdMcEEwM25GN0d2aEF3PT0KPC9QUkU+CjxBRERSRVNTPgo8L0FE RFJFU1M+CjwvQk9EWT48L0hUTUw+ --------------010609050500020105050201-- --------------050203050201070902020808-- From nobody Wed Sep 16 13:45:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333FC1A1A97; Wed, 16 Sep 2015 13:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwGr5MDdZr4F; Wed, 16 Sep 2015 13:45:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83A1A1A8F; Wed, 16 Sep 2015 13:45:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1204C180471; Wed, 16 Sep 2015 13:45:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150916204512.1204C180471@rfc-editor.org> Date: Wed, 16 Sep 2015 13:45:12 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7636 on Proof Key for Code Exchange by OAuth Public Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 20:45:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7636 Title: Proof Key for Code Exchange by OAuth Public Clients Author: N. Sakimura, Ed., J. Bradley, N. Agarwal Status: Standards Track Stream: IETF Date: September 2015 Mailbox: n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com, naa@google.com Pages: 20 Characters: 39482 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-spop-15.txt URL: https://www.rfc-editor.org/info/rfc7636 DOI: http://dx.doi.org/10.17487/RFC7636 OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Sep 16 18:28:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467321A90FC for ; Wed, 16 Sep 2015 18:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvx3gWQe2Hh0 for ; Wed, 16 Sep 2015 18:27:59 -0700 (PDT) Received: from out4133-2.mail.aliyun.com (out4133-2.mail.aliyun.com [42.120.133.2]) by ietfa.amsl.com (Postfix) with ESMTP id BBBAC1A90F6 for ; Wed, 16 Sep 2015 18:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1442453278; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=bRjV4T+WJ9PiH1vpT8sVQ94P8aYopAy1aauC8ctCDSQ=; b=tWnTW2K010jKQEuQ+Ft21kr/NBOmKLpsAaMCb+2tyFClMuS+G1jAQ61ZeEsQQ+t7GqIt/zb15iDwZEOWLgRtwZW921jPND60e1yLntRwPpnMzwPfTcuyOJMWvuUqmCKK4daHASyVxI2o05D3RM4Zozt/RbBxQgooGpTEnas+KLc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R131e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03302; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=6; SR=0; Received: from 10.1.152.130(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.183) by smtp.aliyun-inc.com(127.0.0.1); Thu, 17 Sep 2015 09:27:53 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 17 Sep 2015 09:27:45 +0800 From: "Kepeng Li" To: , , , , Message-ID: Thread-Topic: PoP Architecture: IPR Confirmation Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3525326873_33183402" Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] PoP Architecture: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 01:28:01 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3525326873_33183402 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hi Phil, Justin, William, Prateek ahd Hannes, I am working on the shepherd writeup for the PoP Architecture document: https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt One item in the template requires me to indicate whether each document author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Could you please confirm? Kind Regards Kepeng --B_3525326873_33183402 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable 
Hi Phil, Justin, William, P=
rateek ahd Hannes,

I am working on the shepherd writeup for the PoP Architecture document:
https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt
One item in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng
--B_3525326873_33183402-- From nobody Wed Sep 16 18:59:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7465E1A92B8 for ; Wed, 16 Sep 2015 18:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mOxWJ8fvp7p for ; Wed, 16 Sep 2015 18:59:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ECC1A92BA for ; Wed, 16 Sep 2015 18:59:15 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8H1x9MX007385 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Sep 2015 01:59:09 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8H1x8Zf010229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2015 01:59:08 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8H1x7NM013421; Thu, 17 Sep 2015 01:59:07 GMT Received: from dhcp-whq-2op-6th-and-7th-floor-gen-off-10-209-43-149.usdhcp.oraclecorp.com (/10.209.43.149) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Sep 2015 18:59:07 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_CB4B0E20-C196-4BA6-80CF-300ED027A512" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Prateek Mishra In-Reply-To: Date: Wed, 16 Sep 2015 18:59:10 -0700 Message-Id: References: To: Kepeng Li X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: phil.hunt@yahoo.com, wmills@yahoo-inc.com, ietf@justin.richer.org, oauth@ietf.org Subject: Re: [OAUTH-WG] PoP Architecture: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 01:59:17 -0000 --Apple-Mail=_CB4B0E20-C196-4BA6-80CF-300ED027A512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii confirmed -=20 prateek mishra > On Sep 16, 2015, at 6:27 PM, Kepeng Li = wrote: >=20 > Hi Phil, Justin, William, Prateek ahd Hannes, >=20 > I am working on the shepherd writeup for the PoP Architecture = document: > https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt = > One item in the template requires me to indicate whether > each document author has confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP = 78 > and BCP 79 have already been filed. >=20 > Could you please confirm? >=20 > Kind Regards > Kepeng --Apple-Mail=_CB4B0E20-C196-4BA6-80CF-300ED027A512 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 confirmed  - 

prateek mishra

On = Sep 16, 2015, at 6:27 PM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Hi Phil, Justin, William, Prateek ahd Hannes,

I am working on the shepherd writeup for the PoP Architecture =
document:
https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.tx=
t
One item in the template requires me to =
indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng

= --Apple-Mail=_CB4B0E20-C196-4BA6-80CF-300ED027A512-- From nobody Wed Sep 16 19:06:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD551A92ED for ; Wed, 16 Sep 2015 19:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aos1WARqb7lC for ; Wed, 16 Sep 2015 19:06:31 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61AC1A92EE for ; Wed, 16 Sep 2015 19:06:28 -0700 (PDT) X-AuditID: 1209190f-f799c6d000001933-d2-55fa2022a470 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 60.81.06451.3202AF55; Wed, 16 Sep 2015 22:06:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t8H26P6o032109; Wed, 16 Sep 2015 22:06:26 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t8H26MlJ020916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Sep 2015 22:06:23 -0400 To: Prateek Mishra , Kepeng Li References: From: Justin Richer Message-ID: <55FA2019.2000802@mit.edu> Date: Wed, 16 Sep 2015 22:06:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080305010702020904020503" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsUixCmqraus8CvUYPo8Fotdr5tYLC7PL7I4 +fYVm8WbhcdZLba8ncZu8b6/2oHNY+LbjyweS5b8ZPKYNO0Di8fHp7dYPO6s+sXoMWvWYaYA tigum5TUnMyy1CJ9uwSujJvXmxgLXspV7H3zmrmB8Y14FyMnh4SAicS0FQtZIGwxiQv31rN1 MXJxCAksZpLo/XWBGcLZyChxecN2VgjnNpPErfYmJpAWYQEriWU/DrKB2CIC8RLvr01jBLGF BLIlJs38zQpiMwvESSxf+gfMZhNQlZi+pgWsl1dATWL9+gawOAtQ/Pu6eWC9ogIxEj2/NrBB 1AhKnJz5BOw8TgE7iZaeK4wQM8MklrctZZ7AKDALSdksJCkI20yia2sXI4QtL7H97RyouJrE 7W1X2WHizVtnMy9gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mil5pSuokRHD+S/DsY vx1UOsQowMGoxMP74tmPUCHWxLLiytxDjJIcTEqivLulf4UK8SXlp1RmJBZnxBeV5qQWH2KU 4GBWEuGdKQCU401JrKxKLcqHSUlzsCiJ8276wRciJJCeWJKanZpakFoEk5Xh4FCS4OWTB2oU LEpNT61Iy8wpQUgzcXCCDOcBGv5DDmR4cUFibnFmOkT+FKOilDgvI0izAEgiozQPrheU3hLe HjZ9xSgO9Iow73qQKh5gaoTrfgU0mAlosHvqN5DBJYkIKakGxrbbJxpn3U70DF69VaNhykWz gGurOTNdBRIeWv2pO5Ky9brmgQl5359r/jm0wrJDbIr7ijTlls1yATkJzJGHckwbM69Xxau+ uui28nq4SiRrKFdF++k+oQM+yyXWBjq0PLDyfJcQxid8lPnXVpW3IRv7uWotcz6o5+pvnC4V c8pm9/mmLxJOSizFGYmGWsxFxYkAzwz16UoDAAA= Archived-At: Cc: phil.hunt@yahoo.com, wmills@yahoo-inc.com, ietf@justin.richer.org, oauth@ietf.org Subject: Re: [OAUTH-WG] PoP Architecture: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 02:06:34 -0000 This is a multi-part message in MIME format. --------------080305010702020904020503 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have no IPR disclosures to make. -- Justin On 9/16/2015 9:59 PM, Prateek Mishra wrote: > confirmed - > > prateek mishra > >> On Sep 16, 2015, at 6:27 PM, Kepeng Li > > wrote: >> >> Hi Phil, Justin, William, Prateek ahd Hannes, >> >> I am working on the shepherd writeup for the PoP Architecture document: >> https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt >> One item in the template requires me to indicate whether >> each document author has confirmed that any and all appropriate IPR >> disclosures required for full conformance with the provisions of BCP 78 >> and BCP 79 have already been filed. >> >> Could you please confirm? >> >> Kind Regards >> Kepeng > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080305010702020904020503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I have no IPR disclosures to make.
 -- Justin

On 9/16/2015 9:59 PM, Prateek Mishra wrote:
confirmed  - 

prateek mishra

On Sep 16, 2015, at 6:27 PM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Hi Phil, Justin, William, Prateek ahd Hannes,

I am working on the shepherd writeup for the PoP Architecture document:
https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt
One item in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng



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

--------------080305010702020904020503-- From nobody Wed Sep 16 20:20:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E924A1ACE9A for ; Wed, 16 Sep 2015 20:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b0Axdrxh7cp for ; Wed, 16 Sep 2015 20:20:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C931ACE83 for ; Wed, 16 Sep 2015 20:20:16 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8H3K9sd003484 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Sep 2015 03:20:10 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8H3K9iL031083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2015 03:20:09 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t8H3K8hn009879; Thu, 17 Sep 2015 03:20:08 GMT Received: from [25.87.153.200] (/72.143.225.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Sep 2015 20:20:07 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-A0580DD8-25BF-45B7-9087-4552F9C3B529 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: <55FA2019.2000802@mit.edu> Date: Wed, 16 Sep 2015 20:19:58 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <55FA2019.2000802@mit.edu> To: Justin Richer X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "phil.hunt@yahoo.com" , "wmills@yahoo-inc.com" , "oauth@ietf.org" , "ietf@justin.richer.org" Subject: Re: [OAUTH-WG] PoP Architecture: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 03:20:18 -0000 --Apple-Mail-A0580DD8-25BF-45B7-9087-4552F9C3B529 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Confirmed Phil > On Sep 16, 2015, at 19:06, Justin Richer wrote: >=20 > I have no IPR disclosures to make. > -- Justin >=20 >> On 9/16/2015 9:59 PM, Prateek Mishra wrote: >> confirmed -=20 >>=20 >> prateek mishra >>=20 >>> On Sep 16, 2015, at 6:27 PM, Kepeng Li wrot= e: >>>=20 >>> Hi Phil, Justin, William, Prateek ahd Hannes, >>>=20 >>> I am working on the shepherd writeup for the PoP Architecture document: >>> https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt >>> One item in the template requires me to indicate whether >>> each document author has confirmed that any and all appropriate IPR >>> disclosures required for full conformance with the provisions of BCP 78 >>> and BCP 79 have already been filed. >>>=20 >>> Could you please confirm? >>>=20 >>> Kind Regards >>> Kepeng >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-A0580DD8-25BF-45B7-9087-4552F9C3B529 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Confirmed

Phil

On= Sep 16, 2015, at 19:06, Justin Richer <jricher@mit.edu> wrote:

=20 =20 =20 I have no IPR disclosures to make.
 -- Justin

On 9/16/2015 9:59 PM, Prateek Mishra wrote:
confirmed  - 

prateek mishra

On Sep 16, 2015, at 6:27 PM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Hi Phil, Justin, William, Prateek ahd Hann=
es,

I am working on the shepherd writeup for the PoP Architecture document:
                  
https=
://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt

                  
One item in the template requires me to in=
dicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards

                  
Kepeng

                



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

=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-A0580DD8-25BF-45B7-9087-4552F9C3B529-- From nobody Thu Sep 17 06:09:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287A11B2E70 for ; Thu, 17 Sep 2015 06:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1IJuG_zK_-W for ; Thu, 17 Sep 2015 06:09:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843D81B2E7D for ; Thu, 17 Sep 2015 06:06:49 -0700 (PDT) Received: from [192.168.10.183] ([134.76.0.127]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Ldbqw-1Ytq8x36RO-00ik0Q; Thu, 17 Sep 2015 15:06:41 +0200 To: Kepeng Li , phil.hunt@yahoo.com, ietf@justin.richer.org, wmills@yahoo-inc.com, prateek.mishra@oracle.com References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55FABADA.1020003@gmx.net> Date: Thu, 17 Sep 2015 15:06:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="g0DPnexr6Fu5eveRbmMigRS4dcv5MJ9Lt" X-Provags-ID: V03:K0:fUpmgjjxH4h4Ds9Pu8Y34L9WIiivN+eVMAHmAm3Lji/T4D+ibiV 69/oTo0Q3aGCkC9Xs/7GPic+/Z/tkpLBIUsIZfZS/zhc+25On0QjbY0amMcfj88AGcgkmk4 1YYq5ii9vdBiTVZMoAMRK3F2dEvbOTq9QGG7owpukVZsSSwf66RSa4ur9sfeVSxntzL4H1z nsCJWNIUUbN4DPLaxn07Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:5B0ZWJ1HVog=:akQ57QOGAPIGPpOf1tllxy EfGyVGUosUwnOuCyj4o+xFkvRh44sASQIUzPZDSs3YIhNhLSEikkq8XnMZ82hUV8xY3HNDQoh IvUqyYomvinI/dpz9+RLkZgyYai5uWTJV675bT0Xuj9c328I6PzARDaMM/mQ3EibSPJn08nQD /xwAL7a9ExIY30Nrf2FUTeIuctOFPZzBMqs1RZjIOdaEybIF2nmPPgVFbWnsyPS2dkwXhKT1O pKt+rnL9brby+wAUlc7pDZzQ1Y9uYEis+jh3mnn2rqbbSdn3Arl9yCAi5BVVrb15aPk3mLJxR cIZH6BN1Yoppj+XITBf5XYmO4ZgH9+pCreSAtf+rzUhtRjE/G5xtHLgZRCh0vxrBpMA8CO8N3 YtKB6pgLk+ux4mVQ6DTv4Xj+pttboNqwFsOKhihg82GEvIgWMPe1tVYXY2C8ur8hmGEf6pd6o ajrvOCXgwpAOW+IQgFO62Z0jQPoaY3MdGB+h2bhm0knuVAtBqNvTYa0tlmibIsCR4wmCqVvA5 pQ45/zniin4Je4W6XWkKbSbRkBu6orIDTdrU6RZfZWLaWjkaGQntnIuUugPpD4rU3tqlQTaja m/JqGYNeOaeEueZ7y3sAT8uAGo6ZnMEx9P/d2jULfvFQT1BW8puGivsEOsUz6NsPuXlY3jjFT hAYBv6fwnBX1yiKVvmhFZRFFTSRXDtqhF7J7I8hei1xhg+lR2DRTfH6E3nNojycSF421LF9nw XrI8gPa0WjGWjGn2 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] PoP Architecture: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 13:09:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g0DPnexr6Fu5eveRbmMigRS4dcv5MJ9Lt Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: quoted-printable I am not aware of any IPRs on draft-ietf-oauth-pop-architecture-02.txt On 09/17/2015 03:27 AM, Kepeng Li wrote: > Hi Phil, Justin, William, Prateek ahd Hannes, >=20 > I am working on the shepherd writeup for the PoP Architecture document:= >=20 > https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt >=20 > One item in the template requires me to indicate whether > each document author has confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78= > and BCP 79 have already been filed. >=20 > Could you please confirm? >=20 > Kind Regards >=20 > Kepeng >=20 --g0DPnexr6Fu5eveRbmMigRS4dcv5MJ9Lt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV+rraAAoJEGhJURNOOiAtK8oIAIrWBP6WfwalB5CjtdWjD+j4 WnLd1O+xzJuW8grD/76tKM38uA1ZrvEU2yN0m37qKY/lhQec3jJCfk4O7zjsGJUb LrNz4TVT6QqNrNuTxX2pRhYWeCwX2+4hbs7eFgdpMKBDQ2gBq+OGeR7Ad6Nagsn7 1ZnI6zMIkmJzZBDKux2dncQVY07U7NRYG0BPZJqUGby9Du9XiGJSwSeu4/S2WpEk FkQYvLOgzR8Tzh5KxNvouNRLUVUDJD574fsEx8KuBnEJf69GTT1QO4DM3wLqA6O4 usBjXm0dJOCVdDmgr7+4NcEqtEbw3+gdNt0SnHuDjm/qBJqfU8hJlWdlXjn6n8E= =ik9s -----END PGP SIGNATURE----- --g0DPnexr6Fu5eveRbmMigRS4dcv5MJ9Lt-- From nobody Thu Sep 17 09:24:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C47B1A0041 for ; Thu, 17 Sep 2015 09:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lURc0a6Fphm for ; Thu, 17 Sep 2015 09:24:07 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60081A0061 for ; Thu, 17 Sep 2015 09:24:00 -0700 (PDT) X-AuditID: 1209190c-f79b76d000007c4e-4e-55fae91f1fb6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 0A.DE.31822.F19EAF55; Thu, 17 Sep 2015 12:23:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t8HGNwa3028147 for ; Thu, 17 Sep 2015 12:23:59 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t8HGNv4p027892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 17 Sep 2015 12:23:58 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_128F85A6-575B-4FC5-9807-6839F96C02BD" Message-Id: <17A1B769-8602-46AE-A035-41801237CF69@mit.edu> Date: Thu, 17 Sep 2015 12:23:57 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrCv/8leoQe8pWYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8P2sIL74hW3tixnbmBcK9LFyMkhIWAi8af/HDOELSZx4d56 ti5GLg4hgcVMEjdWnGOCcI4xSlw795cFwvnGJLFy8gQWkBY2AVWJ+StvMYHYzAIJEnt/rWbs YuTgEBbQkjg8sRYkzCtgJdFy8R8biM0CVL70Uy9YuYiAusSa8z+ZIGr0JF7duswKcYWsxO7f j5gmMPLOQjJ1FpIyiLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRNiW3Sjc3MTOnODVZ tzg5MS8vtUjXUC83s0QvNaV0EyM4JCV5djC+Oah0iFGAg1GJh7fC7VeoEGtiWXFl7iFGSQ4m JVHeO8+BQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4F+wByvGmJFZWpRblw6SkOViUxHk3/eAL ERJITyxJzU5NLUgtgsnKcHAoSfDOfAHUKFiUmp5akZaZU4KQZuLgBBnOAzQ8HqSGt7ggMbc4 Mx0if4pRUUqcdx/IRQIgiYzSPLheUMpIeHvY9BWjONArwrwXQKp4gOkGrvsV0GAmoMGvYsEG lyQipKQaGJmP8G1o5ygwnNDrPVF+wm/3vf99g6cWbtnfG7ZAwOaCjdb1lRYOnya/n6jzau/x z0dsz+aEcQrxiWx7uehJZ+Qb9YxW202H7i10nCPkapd8uzdnX02N2uxp0Wdu3jqnG242s3p1 rXb7umOKabkFNjsmexz8KTyvMFhzRWJ5UHWqo3zH71s2b5VYijMSDbWYi4oTARmxroP0AgAA Archived-At: Subject: [OAUTH-WG] New OAuth book: OAuth 2 in Action X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 16:24:09 -0000 --Apple-Mail=_128F85A6-575B-4FC5-9807-6839F96C02BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Everyone, Antonio Sanso and I are writing a book together about OAuth 2, and = it=E2=80=99s just gone live for pre-order today. It=E2=80=99s called = OAuth 2 In Action, and you can download the first chapter for free on = the publisher=E2=80=99s website: https://www.manning.com/books/OAuth-2-in-Action = If you pre-order it today, you=E2=80=99ll get the first three chapters = right away and will keep getting updates and new chapters as they=E2=80=99= re completed and/or refined. You=E2=80=99ll be able to give your input = to the book as we write it, helping form the final content. You=E2=80=99ll= also get the final eBook when it=E2=80=99s released sometime next year.=20= We=E2=80=99re putting a lot of effort into this project and hope it will = be an informative, useful, and entertaining book. Also, for the next few days, you can order it at half-off with the code = mloauth2=20 Thanks, =E2=80=94 Justin (& Antonio)= --Apple-Mail=_128F85A6-575B-4FC5-9807-6839F96C02BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Everyone,

Antonio = Sanso and I are writing a book together about OAuth 2, and it=E2=80=99s = just gone live for pre-order today. It=E2=80=99s called OAuth 2 In = Action, and you can download the first chapter for free on the = publisher=E2=80=99s website:

https://www.manning.com/books/OAuth-2-in-Action

If you pre-order it = today, you=E2=80=99ll get the first three chapters right away and will = keep getting updates and new chapters as they=E2=80=99re completed = and/or refined. You=E2=80=99ll be able to give your input to the book as = we write it, helping form the final content. You=E2=80=99ll also get the = final eBook when it=E2=80=99s released sometime next = year. 

We=E2=80=99re putting a lot of effort into this project and = hope it will be an informative, useful, and entertaining book.

Also, for the next few = days, you can order it at half-off with the code = mloauth2 

Thanks,
 =E2=80=94 Justin (& = Antonio)
= --Apple-Mail=_128F85A6-575B-4FC5-9807-6839F96C02BD-- From nobody Thu Sep 17 13:57:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AFB1A0338 for ; Thu, 17 Sep 2015 13:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA4KkjMMsqOL for ; Thu, 17 Sep 2015 13:57:03 -0700 (PDT) Received: from p3plsmtpa06-07.prod.phx3.secureserver.net (p3plsmtpa06-07.prod.phx3.secureserver.net [173.201.192.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315741A0273 for ; Thu, 17 Sep 2015 13:57:03 -0700 (PDT) Received: from [192.168.1.25] ([94.67.184.181]) by p3plsmtpa06-07.prod.phx3.secureserver.net with id JLwz1r00E3vEbYm01Lx1t9; Thu, 17 Sep 2015 13:57:02 -0700 To: oauth@ietf.org References: <17A1B769-8602-46AE-A035-41801237CF69@mit.edu> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <55FB291B.6020107@connect2id.com> Date: Thu, 17 Sep 2015 23:56:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <17A1B769-8602-46AE-A035-41801237CF69@mit.edu> Content-Type: multipart/alternative; boundary="------------010503030508030209020306" Archived-At: Subject: Re: [OAUTH-WG] New OAuth book: OAuth 2 in Action X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:57:05 -0000 This is a multi-part message in MIME format. --------------010503030508030209020306 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Praise for dedicating a whole part to impl vulnerabilities! Just pre-ordered a copy :) Vladimir On 17.09.2015 19:23, Justin Richer wrote: > Hi Everyone, > > Antonio Sanso and I are writing a book together about OAuth 2, and it=92= s just gone live for pre-order today. It=92s called OAuth 2 In Action, an= d you can download the first chapter for free on the publisher=92s websit= e: > > https://www.manning.com/books/OAuth-2-in-Action > > If you pre-order it today, you=92ll get the first three chapters right = away and will keep getting updates and new chapters as they=92re complete= d and/or refined. You=92ll be able to give your input to the book as we w= rite it, helping form the final content. You=92ll also get the final eBoo= k when it=92s released sometime next year.=20 > > We=92re putting a lot of effort into this project and hope it will be a= n informative, useful, and entertaining book. > > Also, for the next few days, you can order it at half-off with the code= mloauth2=20 > > Thanks, > =97 Justin (& Antonio) > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------010503030508030209020306 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Praise for dedicating a whole part to impl vulnerabilities!

Just pre-ordered a copy :)

Vladimir

On 17.09.2015 19:23, Justin Richer wrote:
Hi Everyone,

Antonio Sanso and I are writing a book together about OAuth 2, and it’s just gone live for pre-order today. It’s called OAuth 2 In Action, and you can download the first chapter for free on the publisher’s website:

https://www.manning.com/books/OAuth-2-in-Action <https://www.manning.com/books/OAuth-2-in-Action>

If you pre-order it today, you’ll get the first three chapters right away and will keep getting updates and new chapters as they’re completed and/or refined. You’ll be able to give your input to the book as we write it, helping form the final content. You’ll also get the final eBook when it’s released sometime next year. 

We’re putting a lot of effort into this project and hope it will be an informative, useful, and entertaining book.

Also, for the next few days, you can order it at half-off with the code mloauth2 

Thanks,
 — Justin (& Antonio)



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


-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com
--------------010503030508030209020306-- From nobody Thu Sep 17 14:06:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378801A03C7 for ; Thu, 17 Sep 2015 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdPfwSTZh-6f for ; Thu, 17 Sep 2015 14:06:28 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF4C1A03AA for ; Thu, 17 Sep 2015 14:06:27 -0700 (PDT) X-AuditID: 1209190f-f799c6d000001933-ec-55fb2b521b26 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id C6.96.06451.25B2BF55; Thu, 17 Sep 2015 17:06:26 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t8HL6Pgv009746; Thu, 17 Sep 2015 17:06:26 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t8HL6Og7010615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Sep 2015 17:06:25 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_6B2A04BD-2E68-4476-A994-1E948B5AC2FF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <55FB291B.6020107@connect2id.com> Date: Thu, 17 Sep 2015 17:06:23 -0400 Message-Id: <4DBAF40B-F511-4742-B66C-46B5ABAB6446@mit.edu> References: <17A1B769-8602-46AE-A035-41801237CF69@mit.edu> <55FB291B.6020107@connect2id.com> To: Vladimir Dzhuvinov X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hRV1g3S/h1qcP21hMXJt6/YLN69+8Do wOQx/3MLq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI+XnzLXDDPsOLgwib2BsZPml2MHBwSAiYS 3/Z6dDFyApliEhfurWfrYuTiEBJYzCTRc2o+M0hCSGAjo8TDtfoQiYdMEmevTmIESTALJEhs uHedHcTmFdCTeHXrMiuILSxgKfHkxi4mEJtNQFVi+poWJpBlnEA1f/6UgoRZgMJPNuxnAQkz C6hLtJ90gZhiJbF8+0RGiLUxElt232IBsUUEDCQevz7PDHGnrMTu34+YJjAKzEJyxCwkR0DE tSWWLXzNDGEbSDztfIVFXF/izbs5TAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbo paaUbmIEh7ok/w7GbweVDjEKcDAq8fAquPwKFWJNLCuuzD3EKMnBpCTKK6fxO1SILyk/pTIj sTgjvqg0J7X4EKMEB7OSCO9tWaAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKY rAwHh5IEb4IWUKNgUWp6akVaZk4JQpqJgxNkOA/Q8FyQGt7igsTc4sx0iPwpRkUpcd4WkIQA SCKjNA+uF5SKEt4eNn3FKA70ijDvdU2gKh5gGoPrfgU0mAlo8KvYXyCDSxIRUlINjFMEAxjP R/4qv84vqW5duZB5ow2T8L2zNrY73HVu/t4raVPwReX9Ja8mXVZ117iDqef3ftdt3rLh87bF s4yObal578Subq6uyjip+tb21/rOgeXBQnd73rkGrLr2cJet24kH1UJJb7Rflb2ZrHthdWWE 4XvB3GUOYQY2DayZjVMrnxi8+HLGXomlOCPRUIu5qDgRAPiwuoAgAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] New OAuth book: OAuth 2 in Action X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 21:06:30 -0000 --Apple-Mail=_6B2A04BD-2E68-4476-A994-1E948B5AC2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That=92s pretty much Antonio=92s section, I=92ll let him take all the = credit for that. :) You can work with us on the forums as those sections = get released into the pre-order bundle to make sure they=92re solid for = the final book. There=92s certainly plenty of material to cover! And thanks!=20 =97 Justin > On Sep 17, 2015, at 4:56 PM, Vladimir Dzhuvinov = wrote: >=20 > Praise for dedicating a whole part to impl vulnerabilities! >=20 > Just pre-ordered a copy :) >=20 > Vladimir >=20 > On 17.09.2015 19:23, Justin Richer wrote: >> Hi Everyone, >>=20 >> Antonio Sanso and I are writing a book together about OAuth 2, and = it=92s just gone live for pre-order today. It=92s called OAuth 2 In = Action, and you can download the first chapter for free on the = publisher=92s website: >>=20 >> https://www.manning.com/books/OAuth-2-in-Action = = = >>=20 >> If you pre-order it today, you=92ll get the first three chapters = right away and will keep getting updates and new chapters as they=92re = completed and/or refined. You=92ll be able to give your input to the = book as we write it, helping form the final content. You=92ll also get = the final eBook when it=92s released sometime next year.=20 >>=20 >> We=92re putting a lot of effort into this project and hope it will be = an informative, useful, and entertaining book. >>=20 >> Also, for the next few days, you can order it at half-off with the = code mloauth2=20 >>=20 >> Thanks, >> =97 Justin (& Antonio) >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > --=20 > Vladimir Dzhuvinov :: vladimir@connect2id.com = __________________________________________= _____ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6B2A04BD-2E68-4476-A994-1E948B5AC2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 That=92s pretty much Antonio=92s section, I=92ll let him take = all the credit for that. :) You can work with us on the forums as those = sections get released into the pre-order bundle to make sure they=92re = solid for the final book. There=92s certainly plenty of material to = cover!

And = thanks! 

 =97 Justin

On = Sep 17, 2015, at 4:56 PM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

=20
Praise for dedicating a whole part to impl vulnerabilities!

Just pre-ordered a copy :)

Vladimir

On 17.09.2015 19:23, Justin Richer wrote:
Hi Everyone,

Antonio Sanso and I are writing a book together about OAuth 2, and it=92s =
just gone live for pre-order today. It=92s called OAuth 2 In Action, and =
you can download the first chapter for free on the publisher=92s =
website:

https://www.manni=
ng.com/books/OAuth-2-in-Action <https://www.m=
anning.com/books/OAuth-2-in-Action>

If you pre-order it today, you=92ll get the first three chapters right =
away and will keep getting updates and new chapters as they=92re =
completed and/or refined. You=92ll be able to give your input to the =
book as we write it, helping form the final content. You=92ll also get =
the final eBook when it=92s released sometime next year.=20

We=92re putting a lot of effort into this project and hope it will be an =
informative, useful, and entertaining book.

Also, for the next few days, you can order it at half-off with the code =
mloauth2=20

Thanks,
 =97 Justin (& Antonio)



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


--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_6B2A04BD-2E68-4476-A994-1E948B5AC2FF-- From nobody Fri Sep 18 07:44:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C501B2D56 for ; Fri, 18 Sep 2015 07:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByxtWrp3rW7p for ; Fri, 18 Sep 2015 07:44:32 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2668A1B2D1A for ; Fri, 18 Sep 2015 07:44:32 -0700 (PDT) X-AuditID: 1209190f-f799c6d000001933-1b-55fc234e25d0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.52.06451.E432CF55; Fri, 18 Sep 2015 10:44:30 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t8IEiUvr000891 for ; Fri, 18 Sep 2015 10:44:30 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t8IEiSNE032267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Sep 2015 10:44:30 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_D7F93DE9-C440-4DAA-89B6-C12915291AEA" Message-Id: <4D69DD0D-19C6-45F7-B81D-E796976419E6@mit.edu> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Fri, 18 Sep 2015 10:44:28 -0400 References: <17A1B769-8602-46AE-A035-41801237CF69@mit.edu> To: "" In-Reply-To: <17A1B769-8602-46AE-A035-41801237CF69@mit.edu> X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrOun/CfU4NE0U4uTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoErY83aNsaCcyoVm1/PZ2xg/CTfxcjJISFgInH9zHcmCFtM4sK9 9WxdjFwcQgKLmSQ2NZ6Gco4xSlztPckMUiUk8I1JYvL2eBCbTUBVYvqaFrBuZoEEiVNbz7GC 2LwCVhKfF36BsvUkXt26DGYLC1hKPLmxC6yeBai3rfs9E8RMK4kDf06A1YgIqEusOf8TLM4p YC2xc8tTZojrZCV2/37ENIGRfxaSdbOQrICIa0ssW/iaGcLWlNjfvZwFU1xDovPbRNYFjGyr GGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxgoNYkn8H47eDSocYBTgYlXh4F3j9 DhViTSwrrsw9xCjJwaQkynua70+oEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHetTeAynlTEiur UovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHhTlYCGChalpqdWpGXmlCCkmTg4 QYbzAA1fpghUw1tckJhbnJkOkT/FqCglztsOkhAASWSU5sH1gpJMwtvDpq8YxYFeEeY9DlLF A0xQcN2vgAYzAQ1+FfsLZHBJIkJKqoGRV+HRiRt1kpu37U2Njf226EVW2Y4b4XY9r3tEN4Rv v+MTpn1X6K4I12ERCUU73gtys3jj/ktqJJhzdeuKRbaGr2QMvr2d8cVWu9B0/qjl80VaE8I+ Pur7O/+1/p5DVmmc2R/k7p5T8TCfb+j2K+Zq9tZ9Oht9HFbfuT+hZkf9dNkqLoWy/yeVWIoz Eg21mIuKEwFjiJ8ODQMAAA== Archived-At: Subject: Re: [OAUTH-WG] New OAuth book: OAuth 2 in Action X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 14:44:34 -0000 --Apple-Mail=_D7F93DE9-C440-4DAA-89B6-C12915291AEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Due to a glitch in the publisher=E2=80=99s website yesterday, the = correct URL is now: https://www.manning.com/books/oauth-2-in-action Sorry for any confusion, =E2=80=94 Justin > On Sep 17, 2015, at 12:23 PM, Justin Richer wrote: >=20 >=20 > Hi Everyone, >=20 > Antonio Sanso and I are writing a book together about OAuth 2, and = it=E2=80=99s just gone live for pre-order today. It=E2=80=99s called = OAuth 2 In Action, and you can download the first chapter for free on = the publisher=E2=80=99s website: >=20 > https://www.manning.com/books/OAuth-2-in-Action = >=20 > If you pre-order it today, you=E2=80=99ll get the first three chapters = right away and will keep getting updates and new chapters as they=E2=80=99= re completed and/or refined. You=E2=80=99ll be able to give your input = to the book as we write it, helping form the final content. You=E2=80=99ll= also get the final eBook when it=E2=80=99s released sometime next year.=20= >=20 > We=E2=80=99re putting a lot of effort into this project and hope it = will be an informative, useful, and entertaining book. >=20 > Also, for the next few days, you can order it at half-off with the = code mloauth2=20 >=20 > Thanks, > =E2=80=94 Justin (& Antonio) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D7F93DE9-C440-4DAA-89B6-C12915291AEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Due to a glitch in the publisher=E2=80=99s website yesterday, = the correct URL is now:

https://www.manning.com/books/oauth-2-in-action

Sorry for any = confusion,
 =E2=80=94 Justin

On Sep 17, 2015, at 12:23 PM, Justin Richer <jricher@MIT.EDU> = wrote:


Hi Everyone,

Antonio = Sanso and I are writing a book together about OAuth 2, and it=E2=80=99s = just gone live for pre-order today. It=E2=80=99s called OAuth 2 In = Action, and you can download the first chapter for free on the = publisher=E2=80=99s website:

https://www.manning.com/books/OAuth-2-in-Action

If you pre-order it = today, you=E2=80=99ll get the first three chapters right away and will = keep getting updates and new chapters as they=E2=80=99re completed = and/or refined. You=E2=80=99ll be able to give your input to the book as = we write it, helping form the final content. You=E2=80=99ll also get the = final eBook when it=E2=80=99s released sometime next = year. 

We=E2=80=99re putting a lot of effort into this project and = hope it will be an informative, useful, and entertaining book.

Also, for the next few = days, you can order it at half-off with the code = mloauth2 

Thanks,
 =E2=80=94 Justin (& = Antonio)
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_D7F93DE9-C440-4DAA-89B6-C12915291AEA-- From nobody Fri Sep 18 09:56:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5398A1A6F1E for ; Fri, 18 Sep 2015 09:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvaVhip8YoTe for ; Fri, 18 Sep 2015 09:56:04 -0700 (PDT) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7C39F1A6EFE for ; Fri, 18 Sep 2015 09:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1442595362; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=33IUmRp6ktweR821eSD3iKAyG3yuSam/j29JbOzS5xM=; b=polb3nP1B9QnoPUkAIT7eMl0q0GkNQDqZRr7zh/rjmzx9jmb8UcoroIVhDfM/x+2ESaB7hKW8G5O8x/HGcoYJFMxIlATfB0JaJQV5TpCWylP1fr/q4xleTvXlIP3PRcM042PAqJf8+rpqdEyotWIqzdzOx5/492JGy3F5fwcnEU= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R211e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03292; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.58.231(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sat, 19 Sep 2015 00:55:54 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 19 Sep 2015 00:55:48 +0800 From: "Kepeng Li" To: Message-ID: Thread-Topic: Review comments to PoP Architecture Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3525468954_38358161" Archived-At: Subject: [OAUTH-WG] Review comments to PoP Architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 16:56:07 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3525468954_38358161 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hello authors, Please find my review comments to PoP Architecture document: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 1. Introduction: At the time of writing the OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token. [Kepeng] This sentences seem to be incomplete. What offers a security mechanism? Also why do we mention =A1=B0at the time of writing=A1=B1? Is the situat= ion changed now? =20 2. Section 3: The main use case that motivates better-than-bearer token security is th= e desire of resource servers to obtain additional assurance that the client is indeed authorized to present an access token. [Kepeng] About =A1=B0better-than-bear=A1=B1, is it a word? Maybe reword the sentenc= e a little bit. =20 3.Section 3.1 1) In a legitimate use case consider chaining of computations whereby a resource server needs to consult other third party resource servers to complete the requested operation. [Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit= ? =20 2) In this use case additional information is conveyed to the resource server to ensure that no entity entity has tampered with the TLS connection= . [Kepeng] Change =A1=B0is conveyed=A1=B1 to =A1=B0should be conveyed=A1=B1? =20 4. Section 3.3: First, an eavesdropper may steal an access token and represent it at a different resource server. [Kepeng] Change =A1=B0represent it at=A1=B1 to =A1=B0present it to=A1=B1? =20 5. Section 3.4: These load balancers may terminate the TLS connection setup and HTTP traffi= c is transmitted in the clear from the load balancer to the resource server. [Kepeng] Don=A1=AFt understand =A1=B0in the clear=A1=B1. Should it be =A1=B0in the wire=A1=B1? Kind Regards Kepeng --B_3525468954_38358161 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable

Hello authors,


Please find my review comments to PoP Architecture = document:

https://tools.ietf.org/html= /draft-ietf-oauth-pop-architecture-02


<= span lang=3D"EN-US">1.     Introduction:

At the time of writing the OAuth 2.0 protocol family ([RFC6749],  &n= bsp; [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token.

[Kepeng]  This sentences seem to be incomplete. What offers a security mechanism? Also why= do we mention “at the time of writing”? Is the situation changed n= ow?

 

2. Section 3:

The main use case that motivates better-than-bearer to= ken security is    the desire of resource servers to obtain additional assurance that    the client is indeed authorized to present an access token.

[Kepeng] About “better-than-bear”, is it a word? Maybe reword the senten= ce a little bit.

 

3.Section 3.1

1) In a legitimate use case consider chaining of compu= tations whereby a resource server needs to consult other third party resource serve= rs to complete the requested operation. 

[Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?

 

2) In this use case additional information is conveyed= to the resource server to ensure that no entity entity has tampered with the T= LS connection.

[Kepeng] Change “is conveyed” to “sh= ould be conveyed”?

 

4. Section 3.3:

First, an eavesdropper may steal an access token and represent it at a different resource server.

[Kepeng] Change “represent it at” to ̶= 0;present it to”?

 

5. Section 3.4:

These load balancers may terminate the TLS connection = setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server.

[Kepeng] Don’t understand “in the clear= 221;. Should it be “in the wire”?


Kind Regards

Kepeng

--B_3525468954_38358161-- From nobody Sat Sep 19 09:02:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADBA1B5FFA for ; Sat, 19 Sep 2015 09:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.351 X-Spam-Level: ** X-Spam-Status: No, score=2.351 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOCAsmxbAgah for ; Sat, 19 Sep 2015 09:02:51 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id D49631B2DE3 for ; Sat, 19 Sep 2015 09:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1442678568; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=E+qggXWLT+kEGO5bB4rsbnIp9Y9ybAAh/crVUF+QK+8=; b=DVgHMgvNyGHtQ6K1OV+hADhQTWOKRr1y5Iexepr8coAE7/wlpRMaqlTYNVnb9qLHG0t12gP5mgTb2vz8dwq99jD9nI3PYdFIHySvHM7jC1CcysRdegkPK/sdSut6Q52BjjPZupskiGxv7egEIbuT1qGjYMrDIPDOvM2oOdWs0Cs= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R211e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03305; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.22.58.129(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 20 Sep 2015 00:02:42 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 20 Sep 2015 00:02:38 +0800 From: "Kepeng Li" To: "Kepeng Li" , Message-ID: Thread-Topic: [OAUTH-WG] Review comments to PoP Architecture Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3525552162_38973998" Archived-At: Subject: Re: [OAUTH-WG] Review comments to PoP Architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 16:02:55 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3525552162_38973998 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Additional comments: 6. Section 4: 1) An attacker may generate a bogus tokens =A1=AD [Kepeng] Change =A1=B0tokens=A1=B1 to =A1=B0token=A1=B1. =20 2) A client may also re-use access tokens for some other resource servers. [Kepeng] Change =A1=B0re-use=A1=B1 to =A1=B0reuse=A1=B1. The pragraph title says =A1=B0reuse=A1=B1.= Also in other places.=20 =20 3) To illustrate key confirmation the first examples borrow from Kerberos and use symmetric key cryptography. [Kepeng] Change =A1=B0the first examples borrow=A1=B1 to =A1=B0the first example is borrowed=A1=B1. =20 7. Section 5.4 1) As a high level message, there are various ways how the threats can be mitigated and while the details of each solution is somewhat different they all ultimately accomplish the goal. [Kepeng] Change the last sentence to: the details of each solution are somewhat different even they all can ultimately accomplish the goal. =20 2) Depending on the chosen layer for providing client-side authentication there may be additional challenges due Web server load balancing, lack of API access to identity information, etc. [Kepeng] Change =A1=B0due=A1=B1 to =A1=B0due to=A1=B1. =20 8. Section 6: [Kepeng] It will be better if we can divide this section into several sub-sections, e.g. each sub-section can be related to each figure. =20 9. Section 7: 1) [Kepeng] Usually the order for a specification is: use cases, requirements, then architecture. Why do we have requirements after architecture? Should we move this section ahead? =20 2) The authorization checking prevents an elevation of privilege attack, an= d it ensures that an unauthorized authorized is detected. [Kepeng] What is =A1=B0an unauthorized authorized=A1=B1? Should it be =A1=B0an unauthor= ized access=A1=B1? Kind Regards Kepeng =B7=A2=BC=FE=C8=CB: Li Kepeng =C8=D5=C6=DA: Saturday, 19 September, 2015 12:55 am =D6=C1: =D6=F7=CC=E2: [OAUTH-WG] Review comments to PoP Architecture Hello authors, Please find my review comments to PoP Architecture document: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 1. Introduction: At the time of writing the OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token. [Kepeng] This sentences seem to be incomplete. What offers a security mechanism? Also why do we mention =A1=B0at the time of writing=A1=B1? Is the situat= ion changed now? =20 2. Section 3: The main use case that motivates better-than-bearer token security is th= e desire of resource servers to obtain additional assurance that the client is indeed authorized to present an access token. [Kepeng] About =A1=B0better-than-bear=A1=B1, is it a word? Maybe reword the sentenc= e a little bit. =20 3.Section 3.1 1) In a legitimate use case consider chaining of computations whereby a resource server needs to consult other third party resource servers to complete the requested operation. [Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit= ? =20 2) In this use case additional information is conveyed to the resource server to ensure that no entity entity has tampered with the TLS connection= . [Kepeng] Change =A1=B0is conveyed=A1=B1 to =A1=B0should be conveyed=A1=B1? =20 4. Section 3.3: First, an eavesdropper may steal an access token and represent it at a different resource server. [Kepeng] Change =A1=B0represent it at=A1=B1 to =A1=B0present it to=A1=B1? =20 5. Section 3.4: These load balancers may terminate the TLS connection setup and HTTP traffi= c is transmitted in the clear from the load balancer to the resource server. [Kepeng] Don=A1=AFt understand =A1=B0in the clear=A1=B1. Should it be =A1=B0in the wire=A1=B1? Kind Regards Kepeng _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --B_3525552162_38973998 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Additional comments:

6. Section 4:

1) An attacker may generate a bogus tokens …

[Kepeng] Change “tokens” to “token&#= 8221;.

 

2) A client may also re-use access tokens for some oth= er resource servers.

[Kepeng] Change “re-use” to “reuse&#= 8221;. The pragraph title says “reuse”. Also in other places.

 

3) To illustrate key confirmation the first examples b= orrow from Kerberos and use symmetric key cryptography.

[Kepeng] Change “the first examples borrow”= ; to “the first example is borrowed”.

 

7. Section 5.4

1) As a high level message, there are various ways how= the threats can be mitigated and while the details of each solution is somewhat= different they all ultimately accomplish the goal.

[Kepeng] Change the last sentence to: the details of e= ach solution are somewhat different even they all can ultimately accomplish the= goal.

 

2) Depending on the chosen layer for providing client-side authentication there may be a= dditional challenges due Web server load balancing, lack of API access to identity information, etc.

[Kepeng] Change “due” to “due to”.

 

8. Section 6:

[Kepeng] It will be better if we can divide this section into several sub-sections, e.g= . each sub-section can be related to each figure.

 

9. Section 7:

1) [Kepeng] Usually the order for a specification is: use cases, requirements, then architecture. Why do we have requirements after architecture? Should we mov= e this section ahead?

 

2) The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authorized is detected.

[Kepeng] What is “an unauthorized authorized”? Should it be “an un= authorized access”?


Kind Regar= ds

Kepeng


=B7=A2=BC=FE=C8=CB: = Li Kepeng <kepeng.lkp= @alibaba-inc.com>
=C8=D5=C6=DA: Sat= urday, 19 September, 2015 12:55 am
=D6=C1: <oauth@ietf.org>
=D6=F7=CC=E2: [OAUTH-WG] Review comments to PoP Archit= ecture

Hello authors,


Please find my review comments to PoP Architecture = document:

https://tools.ietf.org/html= /draft-ietf-oauth-pop-architecture-02


<= span lang=3D"EN-US">1.     Introduction:

At the time of writing the OAuth 2.0 protocol family ([RFC6749],  &n= bsp; [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token.

[Kepeng]  This sentences seem to be incomplete. What offers a security mechanism? Also why= do we mention “at the time of writing”? Is the situation changed n= ow?

 

2. Section 3:

The main use case that motivat= es better-than-bearer token security is    the desire of resource servers to obtain additional assurance that    the client is indeed authorized to present an access token.

<= p class=3D"MsoNormal">[Kepeng] About “better-than-bear”, is it a word? Maybe reword the senten= ce a little bit.

 

3.Section 3.1

1) In a legitimate use case c= onsider chaining of computations whereby a resource server needs to consult other third party resource serve= rs to complete the requested operation. 

[Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?

 

2) In this use case additional information is conveyed to the resource server to ensure that no entity entity has tampered with the T= LS connection.

[Kepeng] Change “is co= nveyed” to “should be conveyed”?

 

4. Section 3.3:

First, an eavesdropper may steal an access token = and represent it at a different resource server.

[Kepeng] Change “represent it at” to “present it to&#= 8221;?

 

5. Section 3.4:

These load balanc= ers may terminate the TLS connection setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server.

[Kepeng] Don’t un= derstand “in the clear”. Should it be “in the wire”?


Kind Regards

Kepeng

_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/= mailman/listinfo/oauth --B_3525552162_38973998-- From nobody Sat Sep 19 12:32:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7141B2BF7 for ; Sat, 19 Sep 2015 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPY4uxkvgGxh for ; Sat, 19 Sep 2015 12:32:43 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4311B2BC7 for ; Sat, 19 Sep 2015 12:32:42 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8JJWZF2023240 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 19 Sep 2015 19:32:37 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8JJWZWc002662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 19 Sep 2015 19:32:35 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8JJWZQr004124; Sat, 19 Sep 2015 19:32:35 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 19 Sep 2015 12:32:34 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-A1C03494-8990-4F12-BDFA-67C4630DDA90 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Sat, 19 Sep 2015 12:32:32 -0700 Content-Transfer-Encoding: 7bit Message-Id: <1975D47A-6BD2-40EE-BA24-FB8C7EB10631@oracle.com> References: To: Kepeng Li X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review comments to PoP Architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 19:32:46 -0000 --Apple-Mail-A1C03494-8990-4F12-BDFA-67C4630DDA90 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Kepeng for the review. I will respond next week.=20 Cheers, Phil > On Sep 19, 2015, at 09:02, Kepeng Li wrote: >=20 > Additional comments: >=20 > 6. Section 4: > 1) An attacker may generate a bogus tokens =E2=80=A6 > [Kepeng] Change =E2=80=9Ctokens=E2=80=9D to =E2=80=9Ctoken=E2=80=9D. > =20 > 2) A client may also re-use access tokens for some other resource servers.= > [Kepeng] Change =E2=80=9Cre-use=E2=80=9D to =E2=80=9Creuse=E2=80=9D. The p= ragraph title says =E2=80=9Creuse=E2=80=9D. Also in other places. > =20 > 3) To illustrate key confirmation the first examples borrow from Kerberos a= nd use symmetric key cryptography. > [Kepeng] Change =E2=80=9Cthe first examples borrow=E2=80=9D to =E2=80=9Cth= e first example is borrowed=E2=80=9D. > =20 > 7. Section 5.4 > 1) As a high level message, there are various ways how the threats can be m= itigated and while the details of each solution is somewhat different they a= ll ultimately accomplish the goal. > [Kepeng] Change the last sentence to: the details of each solution are som= ewhat different even they all can ultimately accomplish the goal. > =20 > 2) Depending on the chosen layer for providing client-side authentication t= here may be additional challenges due Web server load balancing, lack of API= access to identity information, etc. > [Kepeng] Change =E2=80=9Cdue=E2=80=9D to =E2=80=9Cdue to=E2=80=9D. > =20 > 8. Section 6: > [Kepeng] It will be better if we can divide this section into several sub-= sections, e.g. each sub-section can be related to each figure. > =20 > 9. Section 7: > 1) [Kepeng] Usually the order for a specification is: use cases, requireme= nts, then architecture. Why do we have requirements after architecture? Shou= ld we move this section ahead? > =20 > 2) The authorization checking prevents an elevation of privilege attack, a= nd it ensures that an unauthorized authorized is detected. > [Kepeng] What is =E2=80=9Can unauthorized authorized=E2=80=9D? Should it b= e =E2=80=9Can unauthorized access=E2=80=9D? >=20 > Kind Regards > Kepeng >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Li Kepeng > =E6=97=A5=E6=9C=9F: Saturday, 19 September, 2015 12:55 am > =E8=87=B3: > =E4=B8=BB=E9=A2=98: [OAUTH-WG] Review comments to PoP Architecture >=20 > Hello authors, >=20 > Please find my review comments to PoP Architecture document: > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 >=20 > 1. Introduction: > At the time of writing the OAuth 2.0 protocol family ([RFC6749], [RFC67= 50], and [RFC6819]) offer a single standardized security mechanism to access= protected resources, namely the bearer token. > [Kepeng] This sentences seem to be incomplete. What offers a security mec= hanism? Also why do we mention =E2=80=9Cat the time of writing=E2=80=9D? Is t= he situation changed now? > =20 > 2. Section 3: > The main use case that motivates better-than-bearer token security is t= he desire of resource servers to obtain additional assurance that the cli= ent is indeed authorized to present an access token. > [Kepeng] About =E2=80=9Cbetter-than-bear=E2=80=9D, is it a word? Maybe rew= ord the sentence a little bit. > =20 > 3.Section 3.1 > 1) In a legitimate use case consider chaining of computations whereby a re= source server needs to consult other third party resource servers to complet= e the requested operation.=20 > [Kepeng] This sentence seems to be incomplete. Maybe reword it a little bi= t? > =20 > 2) In this use case additional information is conveyed to the resource ser= ver to ensure that no entity entity has tampered with the TLS connection. > [Kepeng] Change =E2=80=9Cis conveyed=E2=80=9D to =E2=80=9Cshould be convey= ed=E2=80=9D? > =20 > 4. Section 3.3: > First, an eavesdropper may steal an access token and represent it at a dif= ferent resource server. > [Kepeng] Change =E2=80=9Crepresent it at=E2=80=9D to =E2=80=9Cpresent it t= o=E2=80=9D? > =20 > 5. Section 3.4: > These load balancers may terminate the TLS connection setup and HTTP traff= ic is transmitted in the clear from the load balancer to the resource server= . > [Kepeng] Don=E2=80=99t understand =E2=80=9Cin the clear=E2=80=9D. Should i= t be =E2=80=9Cin the wire=E2=80=9D? >=20 > Kind Regards > Kepeng > _______________________________________________ OAuth mailing list OAuth@i= etf.org https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-A1C03494-8990-4F12-BDFA-67C4630DDA90 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Kepeng for the review. I will r= espond next week. 

Cheers,

Phil

On Sep 19, 2015, at 09:02, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Additional comments:

6. Section 4:

1) An attacker may generate a bogus tokens =E2=80=A6<= o:p>

[Kepeng] Change =E2=80=9Ctokens=E2=80=9D to =E2=80=9C= token=E2=80=9D.

 

2) A client may also re-use access tokens for some ot= her resource servers.

[Kepeng] Change =E2=80=9Cre-use=E2=80=9D to =E2=80=9C= reuse=E2=80=9D. The pragraph title says =E2=80=9Creuse=E2=80=9D. Also in other places.

 

3) To illustrate key confirmation the first examples b= orrow from Kerberos and use symmetric key cryptography.

[Kepeng] Change =E2=80=9Cthe first examples borrow=E2= =80=9D to =E2=80=9Cthe first example is borrowed=E2=80=9D.

 

7. Section 5.4

1) As a high level message, there are various ways ho= w the threats can be mitigated and while the details of each solution is somewhat different they all ultimately accomplish the goal.

[Kepeng] Change the last sentence to: the details of e= ach solution are somewhat different even they all can ultimately accomplish the goal.

 

2) Depending on the chosen layer for providing client-side authentication there may be ad= ditional challenges due Web server load balancing, lack of API access to identity information, etc.

[Kepeng] Change =E2=80=9Cdue=E2=80=9D to =E2=80=9Cdue to=E2=80=9D.<= /p>

 

8. Section 6:

[Kepeng] It will be better if we can divide this section into several sub-sections, e.g.= each sub-section can be related to each figure.

 

9. Section 7:

1) [Kepeng] Usually the order for a specification is: use cases, requirements, then architecture. Why do we have requirements after architecture? Should we move= this section ahead?

 

2) The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authorized is detected.

[Kepeng] What is =E2=80=9Can unauthorized authorized=E2=80=9D? Should it be =E2=80=9C= an unauthorized access=E2=80=9D?


Kind Regards

Kepeng


=E5= =8F=91=E4=BB=B6=E4=BA=BA: Li Kepeng <kepeng.lkp@alibaba-inc.com>
=E6=97=A5=E6=9C=9F: Saturday, 19 September, 2015 12:55 a= m
=E8=87=B3: <oauth@ietf.org>
=E4=B8=BB=E9=A2=98: [OAUTH-WG] Review comments to PoP Architecture=

Hello authors,


Please find my review comments to PoP Architecture= document:

https://tools.ietf.org/htm= l/draft-ietf-oauth-pop-architecture-02


1.     Introduction:

At the time of writing the OAuth 2.0 protocol family ([RFC6749],  &nb= sp; [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token.

[Kepeng]  This sentences seem to be incomplete. What offers a security mechanism? Also why d= o we mention =E2=80=9Cat the time of writing=E2=80=9D? Is the situation change= d now?

 

2. Section 3:

The main use case that motiva= tes better-than-bearer token security is    the desire of resource servers to obtain additional assurance that    the client is indeed authorized to present an access token.

[Kepeng] About =E2=80=9Cbetter-than-bear=E2=80=9D, is it a word? Maybe reword the sen= tence a little bit.

 

3.Secti= on 3.1

1) In a legitimate use case c= onsider chaining of computations whereby a resource server needs to consult other third party resource server= s to complete the requested operation.  <= /span>

[Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?

 

2) In this use case additional information is conveyed to the resource server to ensure that no entity entity has tampered with the TL= S connection.

[Kepeng] Change =E2=80=9Cis= conveyed=E2=80=9D to =E2=80=9Cshould be conveyed=E2=80=9D?

 

4. Section 3= .3:

First, an eavesdropper may steal an= access token and represent it at a different resource server.

[Kepeng] Change =E2=80=9Crepresent it at=E2=80=9D to =E2=80=9Cpresent i= t to=E2=80=9D?

 

5. Section 3.4:

Thes= e load balancers may terminate the TLS connection setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server.

[Kepeng] Don=E2=80=99t= understand =E2=80=9Cin the clear=E2=80=9D. Should it be =E2=80=9Cin the wire=E2=80=9D?


Kind Regards

Kepeng

Additional comments:

6. Section 4:
1) An attacker may = generate a bogus tokens =E2=80=A6
[Kepeng] Change =E2=80=9Ctokens=E2=80=9D to = =E2=80=9Ctoken=E2=80=9D.
[ph] = Agreed.
 
2) A client may also re-use access tokens for some = other resource servers.
[Kepeng] Change =E2=80=9Cre-use=E2=80=9D to = =E2=80=9Creuse=E2=80=9D. The pragraph title says =E2=80=9Creuse=E2=80=9D. Also in other places. =
[ph] Agreed
 
3) To illustrate key confirmation the first examples = borrow from Kerberos and use symmetric key cryptography.
[Kepeng] Change =E2=80=9Ct= he first examples borrow=E2=80=9D to =E2=80=9Cthe first example is borrowed=E2=80=9D.
[PH] = Agreed.
 
7. Section 5.4
1) As a high level message, there are various ways = how the threats can be mitigated and while the details of each solution is = somewhat different they all ultimately accomplish the goal.
[Kepeng] Change the last = sentence to: the details of each solution are somewhat different even they all can ultimately accomplish = the goal.
[ph]

PROPOSED TEXT:
As a high level message, there are various =
ways the threats can
   be mitigated. While the details of each solution are somewhat
   different, they all accomplish the goal of mitigating the =
threats.

 
2) Depending on the chosen layer for providing client-side authentication there may = be additional challenges due Web server load balancing, lack of API access to identity information, etc.
[Kepeng] Change =E2=80=9Cdue=E2=80=9D to =E2=80=9Cdue = to=E2=80=9D.
[ph] Sec 5.4 = Sender Constraints.  Agreed.
 
8. Section 6:
[Kepeng] It will be better if we can divide this section into several sub-sections, = e.g. each sub-section can be related to each = figure.

broke into the following sub-sections:

* Client and Authorization Server = Interaction
 ** Symmetric Keys
 ** = Asymmetric Keys
* Client and Resource Server = Interaction
* Resource and Authorization Server Interaction = (Token Introspection)
 
9. Section 7:
1) [Kepeng] Usually the order for a specification is: use cases, requirements, then architecture. Why do we have requirements after architecture? Should we = move this section ahead?
[ph] = Agreed.  Will move ahead of =E2=80=9CThreat Mitigation=E2=80=9D and = after =E2=80=9CSecurity and Privacy Threats=E2=80=9D = section.

 
2) The authorization checking prevents an elevation of privilege attack, and it ensures that = an unauthorized authorized is detected.
[Kepeng] What is =E2=80=9Can unauthorized authorized=E2=80=9D? Should it be =E2=80=9C= an unauthorized = access=E2=80=9D?
[ph] =  I=E2=80=99m not sure I captured the WG=E2=80=99s intent here. Can = someone suggest a better explanation for = Authorization?
ORIGINAL:
      Client and =
resource server authorization MUST be performed.  These
      entities MUST demonstrate possession of the appropriate keying
      material, without disclosing it.  Authorization is REQUIRED
      whenever a client interacts with an authorization server.  The
      authorization checking prevents an elevation of privilege attack,
      and it ensures that an unauthorized authorized is detected.

PROPOSED:
      Client and =
resource server authorization MUST be performed.  These
      entities MUST demonstrate possession of the appropriate keying
      material, without disclosing it.  Authorization is REQUIRED
      whenever a client interacts with an authorization server. =20
      Authorization checking prevents an elevation of privilege =
attack.


Kind Regards
Kepeng

=C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B= : Li Kepeng <kepeng.lkp@alibaba-inc.com>
=C3=88=C3=95=C3=86=C3=9A: = Saturday, 19 September, 2015 12:55 am
=C3=96=C3=81: <oauth@ietf.org>
=C3=96=C3=B7=C3=8C=C3= =A2: [OAUTH-WG] Review comments to PoP Architecture

Hello authors,


Please find my review comments to = PoP Architecture document:

https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 2


1.     Introduction:

At the time of writing the OAuth 2.0 protocol family = ([RFC6749],    [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely = the bearer token.

[Kepeng]  This sentences seem to be incomplete. What offers a security mechanism? Also = why do we mention =E2=80=9Cat the time of writing=E2=80=9D? Is the situation = changed now?

[PH] Agreed.

PROPOSED= TEXT:
The OAuth 2.0 protocol family ([RFC6749], [RFC6750], = and [RFC6819
]) offer a single token type known as the = =E2=80=9Cbearer=E2=80=9D token to access protected resources.

 
2. Section 3:
The main = use case that motivates better-than-bearer token security is    the desire of resource servers to obtain additional assurance that    the client is indeed authorized to present an access token.
[Kepeng] About =E2=80=9Cbetter-than-bear=E2=80=9D, is it a word? Maybe reword the = sentence a little = bit.
[PH]
PROPOSED TEXT:
The main use case that motivates improvement = upon =E2=80=9Cbearer=E2=80=9D tokens is=E2=80=A6

 
3.Section 3.1
1) In a = legitimate use case consider chaining of computations whereby a resource server needs to consult other third party resource = servers to complete the requested operation. =
[Kepeng] This sentence seems to be incomplete. Maybe reword it a little = bit?
[PH] 
ORIGINAL:
Imagine a scenario where a resource server that receives a =
valid
   access token re-uses it with other resource server.  The reason for
   re-use may be malicious or may well be legitimate.  In a legitimate

use case consider chaining of computations whereby a resource =
server
   needs to consult other third party resource servers to complete the
   requested operation.

PROPOSED TEXT:
In a scenario where a =
resource server receives a valid access token, 
the resource server than =
re-uses it with other resource server.  The 
reason for re-use may be =
malicious or may well be legitimate.  In a 
legitimate case, the =
intent is to support chaining of computations 
whereby a resource =
server needs to consult other third party resource 
servers to complete a =
requested operation.


 
2) In this use case additional information is = conveyed to the resource server to ensure that no entity entity has tampered with = the TLS connection.
[Kepeng] = Change =E2=80=9Cis conveyed=E2=80=9D to =E2=80=9Cshould be = conveyed=E2=80=9D?
[ph] = Agreed (last para of Sec 3.2)
 
4. Section 3.3:
First, an eavesdropper may steal an access token and represent it at a different resource server.
[Kepeng] Change = =E2=80=9Crepresent it at=E2=80=9D to =E2=80=9Cpresent it = to=E2=80=9D?
[ph] = Agreed.
 
5. Section 3.4:
These load balancers may terminate the TLS = connection setup and HTTP traffic is transmitted in the clear from the load balancer to = the resource server.
[Kepeng] Don=E2=80=99t understand =E2=80=9Cin the = clear=E2=80=9D. Should it be =E2=80=9Cin the = wire=E2=80=9D?
[ph]
=
ORIGINAL:
These load balancers may terminate the TLS
   connection setup and HTTP traffic is transmitted in the clear from
   the load balancer to the resource server.

PROPOSED TEXT:
These load balancers may =
terminate the TLS
   connection setup and HTTP traffic is transmitted without TLS =
protection from
   the load balancer to the resource server.


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

= --Apple-Mail=_952D5089-6964-4A8D-8D15-2DB22F4B4D23-- From nobody Mon Sep 21 20:52:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C311A887C for ; Mon, 21 Sep 2015 20:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2joKcvjvPems for ; Mon, 21 Sep 2015 20:51:58 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0172D1A8869 for ; Mon, 21 Sep 2015 20:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1442893916; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=I2/i7mmcBxm7PUt3IS7tRhshW6FaqJf1J7YZUwb+BSY=; b=O272m8evLW4241HkbOsX0Ll7E7trrDBYU3Uv8iD7jSEpKNGhf+hzaIOpcGyAaoHkreGzVuc2LHhNl2saj7Jh1eUlTGOdExsaHF/j9CTrp8NZ9Rikk01CZs7FvIxvwFor58WfTlTpNIbFfHnMlkH57HutD8B5yLT05GKbEqVWQsI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R281e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03310; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.62.52.242(mailfrom:kepeng.lkp@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Tue, 22 Sep 2015 11:51:51 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 22 Sep 2015 07:55:54 +0800 From: "Kepeng Li" To: Phil Hunt Message-ID: Thread-Topic: [OAUTH-WG] Review comments to PoP Architecture References: <683071E1-4663-4C97-A4A8-E4982F6B2301@oracle.com> In-Reply-To: <683071E1-4663-4C97-A4A8-E4982F6B2301@oracle.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3525767511_41261650" Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Review comments to PoP Architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 03:52:05 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3525767511_41261650 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Phil, thanks for the response. A typo, about comment 3, =E2=80=9Ethan" should be =E2=80=9Ethen=E2=80=9C. Others are fine wit= h me. PROPOSED TEXT: In a scenario where a resource server receives a valid access token, the resource server than then re-uses it with other resource server. Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Phil Hunt =E6=97=A5=E6=9C=9F: Tuesday, 22 September, 2015 1:41 am =E8=87=B3: Li Kepeng =E6=8A=84=E9=80=81: =E4=B8=BB=E9=A2=98: Re: [OAUTH-WG] Review comments to PoP Architecture Kepeng, Kepeng, thanks for the review! My responses (to both emails) to are contained in this message prefixed wit= h [ph] below. Pending further comments from the WG over the next day or so, I will post a revision early Wednesday (pacific time). I would like to draw the WG=E2=80=99s attention to my recommendation for Section = 7, comment 2. I=E2=80=99m not sure if I have the definition correct yet. It still se= ems awkward to me. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Sep 19, 2015, at 9:02 AM, Kepeng Li wrote= : >=20 > Additional comments: >=20 > 6. Section 4: > 1) An attacker may generate a bogus tokens =E2=80=A6 > [Kepeng] Change =E2=80=9Ctokens=E2=80=9D to =E2=80=9Ctoken=E2=80=9D. [ph] Agreed. > =20 > 2) A client may also re-use access tokens for some other resource servers= . > [Kepeng] Change =E2=80=9Cre-use=E2=80=9D to =E2=80=9Creuse=E2=80=9D. The pragraph title says =E2=80=9Cr= euse=E2=80=9D. Also in > other places.=20 [ph] Agreed > =20 > 3) To illustrate key confirmation the first examples borrow from Kerberos= and > use symmetric key cryptography. > [Kepeng] Change =E2=80=9Cthe first examples borrow=E2=80=9D to =E2=80=9Cthe first example i= s > borrowed=E2=80=9D. [PH] Agreed. > =20 > 7. Section 5.4 > 1) As a high level message, there are various ways how the threats can be > mitigated and while the details of each solution is somewhat different th= ey > all ultimately accomplish the goal. > [Kepeng] Change the last sentence to: the details of each solution are > somewhat different even they all can ultimately accomplish the goal. [ph] PROPOSED TEXT: As a high level message, there are various ways the threats can be mitigated. While the details of each solution are somewhat different, they all accomplish the goal of mitigating the threats. > =20 > 2) Depending on the chosen layer for providing client-side authentication > there may be additional challenges due Web server load balancing, lack of= API > access to identity information, etc. > [Kepeng] Change =E2=80=9Cdue=E2=80=9D to =E2=80=9Cdue to=E2=80=9D. [ph] Sec 5.4 Sender Constraints. Agreed. > =20 > 8. Section 6: > [Kepeng] It will be better if we can divide this section into several > sub-sections, e.g. each sub-section can be related to each figure. broke into the following sub-sections: * Client and Authorization Server Interaction ** Symmetric Keys ** Asymmetric Keys * Client and Resource Server Interaction * Resource and Authorization Server Interaction (Token Introspection) > =20 > 9. Section 7: > 1) [Kepeng] Usually the order for a specification is: use cases, requirem= ents, > then architecture. Why do we have requirements after architecture? Should= we > move this section ahead? [ph] Agreed. Will move ahead of =E2=80=9CThreat Mitigation=E2=80=9D and after =E2=80=9CSecur= ity and Privacy Threats=E2=80=9D section. > =20 > 2) The authorization checking prevents an elevation of privilege attack, = and > it ensures that an unauthorized authorized is detected. > [Kepeng] What is =E2=80=9Can unauthorized authorized=E2=80=9D? Should it be =E2=80=9Can una= uthorized > access=E2=80=9D? [ph] I=E2=80=99m not sure I captured the WG=E2=80=99s intent here. Can someone suggest= a better explanation for Authorization? ORIGINAL: Client and resource server authorization MUST be performed. These entities MUST demonstrate possession of the appropriate keying material, without disclosing it. Authorization is REQUIRED whenever a client interacts with an authorization server. The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authorized is detected. PROPOSED: Client and resource server authorization MUST be performed. These entities MUST demonstrate possession of the appropriate keying material, without disclosing it. Authorization is REQUIRED whenever a client interacts with an authorization server. Authorization checking prevents an elevation of privilege attack. >=20 > Kind Regards > Kepeng >=20 > =C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Li Kepeng > =C3=88=C3=95=C3=86=C3=9A: Saturday, 19 September, 2015 12:55 am > =C3=96=C3=81: > =C3=96=C3=B7=C3=8C=C3=A2: [OAUTH-WG] Review comments to PoP Architecture >=20 > Hello authors, >=20 >=20 >=20 > Please find my review comments to PoP Architecture document: >=20 > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 >=20 >=20 >=20 > 1. Introduction: >=20 > At the time of writing the OAuth 2.0 protocol family ([RFC6749], [RFC6= 750], > and [RFC6819]) offer a single standardized security mechanism to access > protected resources, namely the bearer token. > [Kepeng] This sentences seem to be incomplete. What offers a security > mechanism? Also why do we mention =E2=80=9Cat the time of writing=E2=80=9D? Is the si= tuation > changed now? [PH] Agreed. PROPOSED TEXT: The OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819 ]) offer a single token type known as the =E2=80=9Cbearer=E2=80=9D token to access prot= ected resources. > =20 > 2. Section 3: > The main use case that motivates better-than-bearer token security is = the > desire of resource servers to obtain additional assurance that the clie= nt is > indeed authorized to present an access token. > [Kepeng] About =E2=80=9Cbetter-than-bear=E2=80=9D, is it a word? Maybe reword the sen= tence a > little bit. [PH] PROPOSED TEXT: The main use case that motivates improvement upon =E2=80=9Cbearer=E2=80=9D tokens is=E2=80=A6 > =20 > 3.Section 3.1 > 1) In a legitimate use case consider chaining of computations whereby a > resource server needs to consult other third party resource servers to > complete the requested operation. > [Kepeng] This sentence seems to be incomplete. Maybe reword it a little b= it? [PH]=20 ORIGINAL: Imagine a scenario where a resource server that receives a valid access token re-uses it with other resource server. The reason for re-use may be malicious or may well be legitimate. In a legitimate use case consider chaining of computations whereby a resource server needs to consult other third party resource servers to complete the requested operation. PROPOSED TEXT: In a scenario where a resource server receives a valid access token, the resource server than re-uses it with other resource server. The reason for re-use may be malicious or may well be legitimate. In a legitimate case, the intent is to support chaining of computations whereby a resource server needs to consult other third party resource servers to complete a requested operation. > =20 > 2) In this use case additional information is conveyed to the resource se= rver > to ensure that no entity entity has tampered with the TLS connection. > [Kepeng] Change =E2=80=9Cis conveyed=E2=80=9D to =E2=80=9Cshould be conveyed=E2=80=9D? [ph] Agreed (last para of Sec 3.2) > =20 > 4. Section 3.3: > First, an eavesdropper may steal an access token and represent it at a > different resource server. > [Kepeng] Change =E2=80=9Crepresent it at=E2=80=9D to =E2=80=9Cpresent it to=E2=80=9D? [ph] Agreed. > =20 > 5. Section 3.4: > These load balancers may terminate the TLS connection setup and HTTP traf= fic > is transmitted in the clear from the load balancer to the resource server= . > [Kepeng] Don=E2=80=99t understand =E2=80=9Cin the clear=E2=80=9D. Should it be =E2=80=9Cin the wi= re=E2=80=9D? [ph] ORIGINAL: These load balancers may terminate the TLS connection setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server. PROPOSED TEXT: These load balancers may terminate the TLS connection setup and HTTP traffic is transmitted without TLS protection from the load balancer to the resource server. >=20 > Kind Regards > Kepeng > _______________________________________________ OAuth mailing list > OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --B_3525767511_41261650 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Phil, thanks for the response.=

A typo, about comment 3, „than" should be &#= 8222;then“. Others are fine with me.

PRO= POSED TEXT:
In a scenario where =
a resource server receives a valid access token, 
the resource server than then re-uses it =
with other resource server. 

Kind Regards
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: Phil Hunt <ph= il.hunt@oracle.com>
=E6=97=A5=E6=9C=9F: = Tuesday, 22 September, 2015 1:41 am
=E8=87=B3: = Li Kepeng <kepeng.lkp= @alibaba-inc.com>
=E6=8A=84=E9=80=81: &= lt;oauth@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [OAUTH-WG] Review comments to PoP Archit= ecture

Ke= peng,

Kepeng, thanks for the review!
My responses (to both emails) t= o are contained in this message prefixed with [ph] below.

Pending further comments from the WG over the ne= xt day or so, I will post a revision early Wednesday (pacific time).

I would like to draw the= WG’s attention to my recommendation for Section 7, comment 2. I’= ;m not sure if I have the definition correct yet. It still seems awkward to = me.

Thanks,

Phil
<= span class=3D"Apple-style-span" style=3D"border-collapse: separate; color: rgb(0= , 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; f= ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2;= text-indent: 0px; text-transform: none; white-space: normal; widows: 2; wor= d-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: non= e; -webkit-text-stroke-width: 0px;">
ph= il.hunt@oracle.com

On Sep 19, 2015, at 9:02 AM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:
Additional comments:

6. Section 4:
1) An attacker may generate a bogu= s tokens …
[Kepeng] Ch= ange “tokens” to “token”.
[ph] Agreed.
 
2) A client may also re-use access tokens for some other resource servers.
[Kepeng] = Change “re-use” to “reuse”. The pragraph title says “reuse”. Also in other places.
[ph] Agreed
=
 
3) To illustrate key confirmation = the first examples borrow from Kerberos and use symmetric key cryptography.
=
[Kepeng] Change “the first examples borrow̶= 1; to “the first example is borrowed”.
[PH] Agreed= .
 
7. Section 5.4
1) As a high level message, t= here are various ways how the threats can be mitigated and while the details of each solution is somewhat= different they all ultimately accomplish the goal.
[Kepeng] Change the last sentence to: the details of= each solution are somewhat different even they all can ultimately accomplish the= goal.
[ph]

PROPOSED TEXT:
As a high l=
evel message, there are various ways the threats can
   be mitigated. While the details of each solution are somewhat
   different, they all accomplish the goal of mitigating the threats.
=

 
2)= Depending on the chosen layer for providing client-side authentication there may be a= dditional challenges due Web server load balancing, lack of API access to identity information, etc.
[Kepeng] Change “due” to “due to”.
<= /div>
[ph] Sec 5.4 Sender Constraints.  Agreed.
 
8. Section 6:
[Kepeng] It will be better if we can divide this section into several sub-sections, e.g= . each sub-section can be related to each figure.

broke into the following sub-section= s:

* Client and Authorization Server Inter= action
 ** Symmetric Keys
 ** Asymmetric Keys<= /div>
* Client and Resource Server Interaction
* Resource and = Authorization Server Interaction (Token Introspection)
 
9. Sectio= n 7:
1) [Kepeng] Usually the order for a specification is: use cases, requirements, then architecture. Why do we have requirements after architecture? Should we mov= e this section ahead?
[ph] Agreed.=  Will move ahead of “Threat Mitigation” and after “S= ecurity and Privacy Threats” section.

 
2) The au= thorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authorized is detected.
[Kepeng] What is “an unauthorized authorized”? Should it be “an un= authorized access”?
[ph] &n= bsp;I’m not sure I captured the WG’s intent here. Can someone su= ggest a better explanation for Authorization?
ORIGINAL:
= 
      Client and resource=
 server authorization MUST be performed.  These
      entities MUST demonstrate possession of the appropriate keying
      material, without disclosing it.  Authorization is REQUIRED
      whenever a client interacts with an authorization server.  The
      authorization checking prevents an elevation of privilege attack,
      and it ensures that an unauthorized authorized is detected.

PROPOSED:
<= div class=3D"">
      Client=
 and resource server authorization MUST be performed.  These
      entities MUST demonstrate possession of the appropriate keying
      material, without disclosing it.  Authorization is REQUIRED
      whenever a client interacts with an authorization server.  
      Authorization checking prevents an elevation of privilege attack.


Kind Regards
Ke= peng

=C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Li Kepe= ng <kepeng.lkp@aliba= ba-inc.com>
=C3=88=C3=95=C3= =86=C3=9A: Saturday, 19 September, 2015 12:55 am
=C3=96=C3=81: <oauth@ietf.org>
=C3=96=C3=B7=C3=8C=C3=A2: [OAUTH-WG] Review comments to PoP Architecture

<= meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" class=3D""><= meta name=3D"ProgId" content=3D"Word.Document" class=3D"">

Hello authors,


Please find my review comments to PoP Arch= itecture document:

https://tools.ietf= .org/html/draft-ietf-oauth-pop-architecture-02


<= span lang=3D"EN-US" class=3D"">1.     Introduction:

At the time of writing the OAuth 2.0 protocol family ([RFC6749],  &n= bsp; [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token.

[Kepeng]  = This sentences seem to be incomplete. What offers a security mechanism? Also why= do we mention “at the time of writing”? Is the situation changed n= ow?

[PH] Agreed.

PROPOSED TEXT:
The= OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819
= ]) offer a single token type known as the “bearer” token to acce= ss protected resources.

<= /div>
 
2. Section 3:
The main use case= that motivates better-than-bearer token security is    the desire of resource servers to obtain additional assurance that    the client is indeed authorized to present an access token.
[Kepeng] About “better-than-bear”, is it a word? Maybe reword the senten= ce a little bit.
[PH= ]
PROPOSED TEXT:
The main use case that motivates improv= ement upon “bearer” tokens is…

 
3.Section 3.1
1) In a legitima= te use case consider chaining of computations whereby a resource server needs to consult other third party resource serve= rs to complete the requested operation. 
[Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?
=
[PH] 
ORIGINAL:
Imagine a scenario where a resour=
ce server that receives a valid
   access token re-uses it with other resource server.  The reason for
   re-use may be malicious or may well be legitimate.  In a legitimate

use case consider =
chaining of computations whereby a resource server
   needs to consult other third party resource servers to complete the
   requested operation.

<= div>PROPOSED TEXT:
In a scenario=
 where a resource server receives a valid access token, 
the resource server than re-uses it with other reso=
urce server.  The 
reason f=
or re-use may be malicious or may well be legitimate.  In a 
legitimate case, the intent is to support chain=
ing of computations 
whereby a r=
esource server needs to consult other third party resource 
servers to complete a requested operation.  

<=
div class=3D"">
 
2) In this use case a= dditional information is conveyed to the resource server to ensure that no entity entity has tampered with the T= LS connection.
[Kepeng] Change= “is conveyed” to “should be conveyed”?
<= /div>
[ph] Agreed (last para of Sec 3.2)
 =
4. Section 3.3:
First, an eavesdropper may steal an access token and represent it at a different resource server.
[Kepeng] Change “represent it at” to “pr= esent it to”?
[ph] Ag= reed.
<= span id=3D"OLK_SRC_BODY_SECTION" class=3D"">
&n= bsp;
5. Section 3.4:
These load balancers may terminate the TLS connec= tion setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server.
[Kepeng] D= on’t understand “in the clear”. Should it be “in the wire”?
[ph]
ORIGINAL:
These load balan=
cers may terminate the TLS
   connection setup and HTTP traffic is transmitted in the clear from
   the load balancer to the resource server.

PROPOSED TEXT:


Kind Regards
Kepeng
_______________________________________________ OAuth mailing list OAuth@ietf.orghttps://www.ietf.org/mailman/= listinfo/oauth
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org<= br class=3D"">https://ww= w.ietf.org/mailman/listinfo/oauth
<= br class=3D"">
 --B_3525767511_41261650-- From nobody Mon Sep 21 22:15:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F601A8AA5 for ; Mon, 21 Sep 2015 22:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kEKb1AKwlnr for ; Mon, 21 Sep 2015 22:15:47 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0428A1A8AA1 for ; Mon, 21 Sep 2015 22:15:46 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8M5FfM5022559 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Sep 2015 05:15:42 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8M5FfO0021645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Sep 2015 05:15:41 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t8M5FepH003736; Tue, 22 Sep 2015 05:15:41 GMT Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Sep 2015 22:15:38 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-574CA59F-B9D0-449E-8E85-2D858B73B391 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Mon, 21 Sep 2015 22:15:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: <809B823F-6444-478C-8AAE-D9DD6947FAB6@oracle.com> References: <683071E1-4663-4C97-A4A8-E4982F6B2301@oracle.com> To: Kepeng Li X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review comments to PoP Architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 05:15:51 -0000 --Apple-Mail-574CA59F-B9D0-449E-8E85-2D858B73B391 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks. I will add to the amended draft.=20 Phil > On Sep 21, 2015, at 16:55, Kepeng Li wrote: >=20 > Phil, thanks for the response. >=20 > A typo, about comment 3, =E2=80=9Ethan" should be =E2=80=9Ethen=E2=80=9C. O= thers are fine with me. >=20 > PROPOSED TEXT: > In a scenario where a resource server receives a valid access token,=20 > the resource server than then re-uses it with other resource server.=20 >=20 > Kind Regards > Kepeng >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Phil Hunt > =E6=97=A5=E6=9C=9F: Tuesday, 22 September, 2015 1:41 am > =E8=87=B3: Li Kepeng > =E6=8A=84=E9=80=81: > =E4=B8=BB=E9=A2=98: Re: [OAUTH-WG] Review comments to PoP Architecture >=20 > Kepeng, >=20 > Kepeng, thanks for the review! >=20 > My responses (to both emails) to are contained in this message prefixed wi= th [ph] below. >=20 > Pending further comments from the WG over the next day or so, I will post a= revision early Wednesday (pacific time). >=20 > I would like to draw the WG=E2=80=99s attention to my recommendation for S= ection 7, comment 2. I=E2=80=99m not sure if I have the definition correct y= et. It still seems awkward to me. >=20 > Thanks, >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Sep 19, 2015, at 9:02 AM, Kepeng Li wrote= : >>=20 >> Additional comments: >>=20 >> 6. Section 4: >> 1) An attacker may generate a bogus tokens =E2=80=A6 >> [Kepeng] Change =E2=80=9Ctokens=E2=80=9D to =E2=80=9Ctoken=E2=80=9D. > [ph] Agreed. >> =20 >> 2) A client may also re-use access tokens for some other resource servers= . >> [Kepeng] Change =E2=80=9Cre-use=E2=80=9D to =E2=80=9Creuse=E2=80=9D. The p= ragraph title says =E2=80=9Creuse=E2=80=9D. Also in other places. > [ph] Agreed >> =20 >> 3) To illustrate key confirmation the first examples borrow from Kerberos= and use symmetric key cryptography. >> [Kepeng] Change =E2=80=9Cthe first examples borrow=E2=80=9D to =E2=80=9Ct= he first example is borrowed=E2=80=9D. > [PH] Agreed. >> =20 >> 7. Section 5.4 >> 1) As a high level message, there are various ways how the threats can be= mitigated and while the details of each solution is somewhat different they= all ultimately accomplish the goal. >> [Kepeng] Change the last sentence to: the details of each solution are so= mewhat different even they all can ultimately accomplish the goal. > [ph] >=20 > PROPOSED TEXT: > As a high level message, there are various ways the threats can > be mitigated. While the details of each solution are somewhat > different, they all accomplish the goal of mitigating the threats. >=20 >> =20 >> 2) Depending on the chosen layer for providing client-side authentication= there may be additional challenges due Web server load balancing, lack of A= PI access to identity information, etc. >> [Kepeng] Change =E2=80=9Cdue=E2=80=9D to =E2=80=9Cdue to=E2=80=9D. > [ph] Sec 5.4 Sender Constraints. Agreed. >> =20 >> 8. Section 6: >> [Kepeng] It will be better if we can divide this section into several sub= -sections, e.g. each sub-section can be related to each figure. >=20 > broke into the following sub-sections: >=20 > * Client and Authorization Server Interaction > ** Symmetric Keys > ** Asymmetric Keys > * Client and Resource Server Interaction > * Resource and Authorization Server Interaction (Token Introspection) >> =20 >> 9. Section 7: >> 1) [Kepeng] Usually the order for a specification is: use cases, requirem= ents, then architecture. Why do we have requirements after architecture? Sho= uld we move this section ahead? > [ph] Agreed. Will move ahead of =E2=80=9CThreat Mitigation=E2=80=9D and a= fter =E2=80=9CSecurity and Privacy Threats=E2=80=9D section. >=20 >> =20 >> 2) The authorization checking prevents an elevation of privilege attack, a= nd it ensures that an unauthorized authorized is detected. >> [Kepeng] What is =E2=80=9Can unauthorized authorized=E2=80=9D? Should it b= e =E2=80=9Can unauthorized access=E2=80=9D? > [ph] I=E2=80=99m not sure I captured the WG=E2=80=99s intent here. Can so= meone suggest a better explanation for Authorization? > ORIGINAL: > Client and resource server authorization MUST be performed. These > entities MUST demonstrate possession of the appropriate keying > material, without disclosing it. Authorization is REQUIRED > whenever a client interacts with an authorization server. The > authorization checking prevents an elevation of privilege attack, > and it ensures that an unauthorized authorized is detected. >=20 > PROPOSED: > Client and resource server authorization MUST be performed. These > entities MUST demonstrate possession of the appropriate keying > material, without disclosing it. Authorization is REQUIRED > whenever a client interacts with an authorization server. =20 > Authorization checking prevents an elevation of privilege attack. >=20 >>=20 >> Kind Regards >> Kepeng >>=20 >> =C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Li Kepeng >> =C3=88=C3=95=C3=86=C3=9A: Saturday, 19 September, 2015 12:55 am >> =C3=96=C3=81: >> =C3=96=C3=B7=C3=8C=C3=A2: [OAUTH-WG] Review comments to PoP Architecture >>=20 >> Hello authors, >>=20 >> Please find my review comments to PoP Architecture document: >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 >>=20 >> 1. Introduction: >> At the time of writing the OAuth 2.0 protocol family ([RFC6749], [RFC6= 750], and [RFC6819]) offer a single standardized security mechanism to acces= s protected resources, namely the bearer token. >> [Kepeng] This sentences seem to be incomplete. What offers a security me= chanism? Also why do we mention =E2=80=9Cat the time of writing=E2=80=9D? Is= the situation changed now? >=20 > [PH] Agreed. >=20 > PROPOSED TEXT: > The OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819 > ]) offer a single token type known as the =E2=80=9Cbearer=E2=80=9D token t= o access protected resources. >=20 >> =20 >> 2. Section 3: >> The main use case that motivates better-than-bearer token security is t= he desire of resource servers to obtain additional assurance that the cli= ent is indeed authorized to present an access token. >> [Kepeng] About =E2=80=9Cbetter-than-bear=E2=80=9D, is it a word? Maybe re= word the sentence a little bit. > [PH] > PROPOSED TEXT: > The main use case that motivates improvement upon =E2=80=9Cbearer=E2=80=9D= tokens is=E2=80=A6 >=20 >> =20 >> 3.Section 3.1 >> 1) In a legitimate use case consider chaining of computations whereby a r= esource server needs to consult other third party resource servers to comple= te the requested operation.=20 >> [Kepeng] This sentence seems to be incomplete. Maybe reword it a little b= it? > [PH]=20 > ORIGINAL: > Imagine a scenario where a resource server that receives a valid > access token re-uses it with other resource server. The reason for > re-use may be malicious or may well be legitimate. In a legitimate > use case consider chaining of computations whereby a resource server > needs to consult other third party resource servers to complete the > requested operation. >=20 > PROPOSED TEXT: > In a scenario where a resource server receives a valid access token,=20 > the resource server than re-uses it with other resource server. The=20 > reason for re-use may be malicious or may well be legitimate. In a=20 > legitimate case, the intent is to support chaining of computations=20 > whereby a resource server needs to consult other third party resource=20 > servers to complete a requested operation. =20 >=20 >=20 >> =20 >> 2) In this use case additional information is conveyed to the resource se= rver to ensure that no entity entity has tampered with the TLS connection. >> [Kepeng] Change =E2=80=9Cis conveyed=E2=80=9D to =E2=80=9Cshould be conve= yed=E2=80=9D? > [ph] Agreed (last para of Sec 3.2) >> =20 >> 4. Section 3.3: >> First, an eavesdropper may steal an access token and represent it at a di= fferent resource server. >> [Kepeng] Change =E2=80=9Crepresent it at=E2=80=9D to =E2=80=9Cpresent it t= o=E2=80=9D? > [ph] Agreed. >> =20 >> 5. Section 3.4: >> These load balancers may terminate the TLS connection setup and HTTP traf= fic is transmitted in the clear from the load balancer to the resource serve= r. >> [Kepeng] Don=E2=80=99t understand =E2=80=9Cin the clear=E2=80=9D. Should i= t be =E2=80=9Cin the wire=E2=80=9D? > [ph] > ORIGINAL: > These load balancers may terminate the TLS > connection setup and HTTP traffic is transmitted in the clear from > the load balancer to the resource server. >=20 > PROPOSED TEXT: > These load balancers may terminate the TLS > connection setup and HTTP traffic is transmitted without TLS protection= from > the load balancer to the resource server. >=20 >>=20 >> Kind Regards >> Kepeng >> _______________________________________________ OAuth mailing list OAuth@= ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-574CA59F-B9D0-449E-8E85-2D858B73B391 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks. I will add to the amended draf= t. 

Phil

On Sep 21, 2015, at 16:55, Kepeng Li <= kepeng.lkp@alibaba-inc.com= > wrote:

Phil, thanks fo= r the response.

A typo, about comment 3, =E2=80=9Et= han" should be =E2=80=9Ethen=E2=80=9C. Others are fine with me.
PROPOSED TEXT:
In a scenario where a resource server receives a valid access token,&nb=
sp;
the resource server t=
han then re-uses it with other resource server. 

Kin=
d Regards
Kepeng
=

=E5=8F=91=E4=BB=B6=E4=BA=BA:= Phil Hunt <phil.hunt@ora= cle.com>
=E6=97=A5=E6=9C=9F: Tuesday, 22 September, 2015 1:41 am
= =E8=87=B3: Li Kepeng <kepeng.lkp@alibaba-inc.com>
=E6= =8A=84=E9=80=81: <oauth@ietf.or= g>
=E4=B8=BB=E9=A2=98: Re= : [OAUTH-WG] Review comments to PoP Architecture

Kepeng,

Kepeng, thanks for the review!

My responses (to both emails) to are containe= d in this message prefixed with [ph] below.

Pending further comments from the WG over the next day o= r so, I will post a revision early Wednesday (pacific time).
<= div class=3D"">
I would like to draw the= WG=E2=80=99s attention to my recommendation for Section 7, comment 2. I=E2=80= =99m not sure if I have the definition correct yet. It still seems awkward t= o me.

Thanks,

Phil
<= div class=3D"">
@independentid
www.independ= entid.com
phil.hunt@oracle.com
=

On Sep 19, 2015, at 9:02 AM, Kepeng Li <kepeng.lkp@alibaba-inc.com= > wrote:

Additional comments= :

6. Section 4:
1) An attacker may generate a= bogus tokens =E2=80=A6
= [Kepeng] Change =E2=80=9Ctokens=E2=80=9D to =E2=80=9Ctoken=E2=80=9D.
[ph] Agreed.
 
2) A client m= ay also re-use access tokens for some other resource servers.
[Kepen= g] Change =E2=80=9Cre-use=E2=80=9D to =E2=80=9Creuse=E2=80=9D. The pragraph t= itle says =E2=80=9Creuse=E2=80=9D. Also in other places.
[ph] Agreed
 
3) To illustrate key confirmation the first examples borrow from Kerberos and use symmetric key cryptography.
[Kepeng] Change =E2=80=9Cthe first examples borrow= =E2=80=9D to =E2=80=9Cthe first example is borrowed=E2=80=9D.
[PH] Agree= d.
 
7. Section 5.4
1) As a high level message, there are various ways how the threats can be mitigated and while the details of each solution is somewhat different they all ultimately accomplish the goal.
[Kepeng] Change the last sentence to: the details= of each solution are somewhat different even they all can ultimately accomplish the goal.
[ph]

PROPOSED TEXT:
As a h=
igh level message, there are various ways the threats can
   be mitigated. While the details of each solution are somewhat
   different, they all accomplish the goal of mitigating the threats.
<= div class=3D"">
 
2) Depending on the chosen layer for providing client-side authentication there may be ad= ditional challenges due Web server load balancing, lack of API access to identity information, etc.
[Kepeng] Change =E2=80=9Cdue=E2=80=9D to =E2=80=9Cdue to=E2=80=9D.
=
[ph] Sec 5.4 Sender Constraints.  Agreed.
 
8. Section 6:
[Kepeng] It will be better if we can divide this section into several sub-sections, e.g.= each sub-section can be related to each figure.

broke into the following sub-sectio= ns:

* Client and Authorization Server In= teraction
 ** Symmetric Keys
 ** Asymmetric Ke= ys
* Client and Resource Server Interaction
* Resource a= nd Authorization Server Interaction (Token Introspection)
=
 
9. Section 7:
1) [Kepeng] Usually the order for a specification is: use cases, requirements, then architecture. Why do we have requirements after architecture? Should we move= this section ahead?
[ph] Agreed. &= nbsp;Will move ahead of =E2=80=9CThreat Mitigation=E2=80=9D and after =E2=80= =9CSecurity and Privacy Threats=E2=80=9D section.

<= blockquote type=3D"cite" class=3D"">
 
2) The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authorized is detected.
[Kepeng] What is =E2=80=9Can unauthorized authorized=E2=80=9D? Should it be =E2=80=9C= an unauthorized access=E2=80=9D?
= [ph]  I=E2=80=99m not sure I captured the WG=E2=80=99s intent here. Can= someone suggest a better explanation for Authorization?
ORIGINAL:= 
      C=
lient and resource server authorization MUST be performed.  These
      entities MUST demonstrate possession of the appropriate keying
      material, without disclosing it.  Authorization is REQUIRED
      whenever a client interacts with an authorization server.  The
      authorization checking prevents an elevation of privilege attack,
      and it ensures that an unauthorized authorized is detected.

PROPOSED:
      Client and resource server authorization MUST be performed.  These
      entities MUST demonstrate possession of the appropriate keying
      material, without disclosing it.  Authorization is REQUIRED
      whenever a client interacts with an authorization server. =20
      Authorization checking prevents an elevation of privilege attack.

<= /span>

Kind Regards
Kepeng

=C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B= : Li Kepeng <kepeng.lkp@alibaba-inc.com>
=C3=88=C3=95=C3=86=C3=9A: Saturday, 19 September= , 2015 12:55 am
=C3= =96=C3=81: <oauth@ie= tf.org>
=C3= =96=C3=B7=C3=8C=C3=A2: [OAUTH-WG] Review comments to PoP Architectur= e

<= meta name=3D"=C2=B1=C3=AA=C3=8C=C3=A2" content=3D"" class=3D"">

Hello authors,


Please find my review comments to PoP A= rchitecture document:

https://tools.i= etf.org/html/draft-ietf-oauth-pop-architecture-02


1.     Introduction:

At the time of writing the OAuth 2.0 protocol family ([RFC6749],  &nb= sp; [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token.

[Kepeng]&nbs= p; This sentences seem to be incomplete. What offers a security mechanism? Also why d= o we mention =E2=80=9Cat the time of writing=E2=80=9D? Is the situation change= d now?

=
[PH] Agreed.

PROPOSED TEXT:
<= div>The OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819
]) offer a single token type known as the =E2=80=9Cbearer=E2=80=9D t= oken to access protected resources.

=
 
2. Section 3:
The main use c= ase that motivates better-than-bearer token security is    the desire of resource servers to obtain additional assurance that    the client is indeed authorized to present an access token.<= /o:p>
[Kepeng]= About =E2=80=9Cbetter-than-bear=E2=80=9D, is it a word? Maybe reword the sen= tence a little bit.
= [PH]
PROPOSED TEXT:
The main use case that motivates imp= rovement upon =E2=80=9Cbearer=E2=80=9D tokens is=E2=80=A6

<= div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-b= reak: after-white-space; font-size: 14px; font-family: =C3=8B=C3=8E=C3=8C=C3= =A5, sans-serif;" class=3D"">
 
<= div class=3D"MsoNormal">3.Section 3.1
1) In a legit= imate use case consider chaining of computations whereby a resource server needs to consult other third party resource server= s to complete the requested operation.  <= o:p class=3D"">
[Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?
<= /div>
[PH] 
ORIGINAL:
Imagine a scenario where a res=
ource server that receives a valid
   access token re-uses it with other resource server.  The reason for
   re-use may be malicious or may well be legitimate.  In a legitimate

use case co=
nsider chaining of computations whereby a resource server
   needs to consult other third party resource servers to complete the
   requested operation.

PROPOSED TEXT:
In a s=
cenario where a resource server receives a valid access token, 
the resource server than re-uses it with= other resource server.  The 
reason for re-use may be malicious or may well be legitimate.  In a&n=
bsp;
legitimate case, the intent i=
s to support chaining of computations 
whereby a resource server needs to consult other third party reso=
urce 
servers to complete a r=
equested operation.


 
2) In this use case additional information is conveyed to the resource server to ensure that no entity entity has tampered with the TL= S connection.
[Kepeng] Cha= nge =E2=80=9Cis conveyed=E2=80=9D to =E2=80=9Cshould be conveyed=E2=80=9D?
[ph] Agreed (last para of Se= c 3.2)
 
4. Section 3.3:
First, an eavesdropper may steal an access token and represent it at a different resource server.
[Kepeng] Change =E2=80=9Crepresent it at=E2=80=9D to =E2= =80=9Cpresent it to=E2=80=9D?
[ph] Agreed.
 
5. Section 3.4:
<= div class=3D"MsoNormal">These load balancers may terminate the TLS connectio= n setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server.
[Kepeng= ] Don=E2=80=99t understand =E2=80=9Cin the clear=E2=80=9D. Should it be =E2=80= =9Cin the wire=E2=80=9D?
[ph]
ORIGINAL:
These load b=
alancers may terminate the TLS
   connection setup and HTTP traffic is transmitted in the clear from
   the load balancer to the resource server.

PROPOSED TEXT:
These load balancers may terminate the TLS
   connection setup and HTTP traffic is transmitted without TLS protection f=
rom
   the load balancer to the resource server.

=

Kind Regards
Kepeng
_______________________________________________ OAuth mailing list OAuth@ietf.orghttps://www.ietf.org/m= ailman/listinfo/oauth
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
= https://www.ietf.org/mailman/listinfo/oauth

 = --Apple-Mail-574CA59F-B9D0-449E-8E85-2D858B73B391-- From nobody Fri Sep 25 11:29:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB631A6F53; Fri, 25 Sep 2015 11:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unLsdOznXVVG; Fri, 25 Sep 2015 11:29:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 687671A6F8F; Fri, 25 Sep 2015 11:29:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150925182944.26745.54213.idtracker@ietfa.amsl.com> Date: Fri, 25 Sep 2015 11:29:44 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 18:29: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 Working Group of the IETF. Title : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Authors : Phil Hunt Justin Richer William Mills Prateek Mishra Hannes Tschofenig Filename : draft-ietf-oauth-pop-architecture-03.txt Pages : 22 Date : 2015-09-25 Abstract: The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must to be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 25 11:33:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB74E1A6FEF for ; Fri, 25 Sep 2015 11:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElBC0sH2bkYj for ; Fri, 25 Sep 2015 11:33:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B661A2182 for ; Fri, 25 Sep 2015 11:33:46 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8PIXjhh008554 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Sep 2015 18:33:45 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8PIXiKD004011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 25 Sep 2015 18:33:45 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t8PIXisU022585 for ; Fri, 25 Sep 2015 18:33:44 GMT Received: from [192.168.1.200] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Sep 2015 11:33:44 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Phil Hunt In-Reply-To: <20150925182944.26745.54213.idtracker@ietfa.amsl.com> Date: Fri, 25 Sep 2015 11:33:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0871F305-800D-44E6-B120-F10D3092936B@oracle.com> References: <20150925182944.26745.54213.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2104) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 18:33:53 -0000 This draft update includes the discussed revisions based on the review = comments from Kepeng. =20 Thanks to Kepeng for the review! Phil @independentid www.independentid.com phil.hunt@oracle.com > On Sep 25, 2015, at 11:29 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Proof-of-Possession (PoP) Security = Architecture > Authors : Phil Hunt > Justin Richer > William Mills > Prateek Mishra > Hannes Tschofenig > Filename : draft-ietf-oauth-pop-architecture-03.txt > Pages : 22 > Date : 2015-09-25 >=20 > Abstract: > The OAuth 2.0 bearer token specification, as defined in RFC 6750, > allows any party in possession of a bearer token (a "bearer") to get > access to the associated resources (without demonstrating possession > of a cryptographic key). To prevent misuse, bearer tokens must to = be > protected from disclosure in transit and at rest. >=20 > Some scenarios demand additional security protection whereby a = client > needs to demonstrate possession of cryptographic keying material = when > accessing a protected resource. This document motivates the > development of the OAuth 2.0 proof-of-possession security mechanism. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-03= >=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 From nobody Fri Sep 25 14:33:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908971A87C8 for ; Fri, 25 Sep 2015 14:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40Z8OOVw3uc2 for ; Fri, 25 Sep 2015 14:33:09 -0700 (PDT) Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B021A87C7 for ; Fri, 25 Sep 2015 14:33:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id C5BCAB41DE for ; Fri, 25 Sep 2015 21:30:47 +0000 (UTC) Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1443216647; x=1444080648; bh=hKppfDMN6F 5sUAoUUx59+LWc0B+v/M0r2HgmXjn0JJs=; b=jNQ6jNPZRDlQ14+WLWvbgS5xlx kbNUKighF4d7M3M2wfEp3HWVnmSWldUKgWsf46PikEl1CQnFk2X9WuhqZ6Se6nRb 3BsaFF0Xj7L8OlX0yoRtHefeLCKqQ8+NeK4+U/BMckBk7ixiYhBdTUZAVXPtNrkp JaMwboaBm805rCkiQ= Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CTY04svR_2S for ; Fri, 25 Sep 2015 21:30:47 +0000 (UTC) Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id 97234B41A6 for ; Fri, 25 Sep 2015 21:30:47 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Sep 2015 16:30:47 -0500 From: Mike Schwartz To: oauth@ietf.org Organization: Gluu In-Reply-To: References: Message-ID: X-Sender: mike@gluu.org User-Agent: Roundcube Webmail Archived-At: Subject: [OAUTH-WG] typo X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 21:33:10 -0000 You have a little typo in the abstract: "bearer tokens must to be protected from disclosure in transit and at rest." I think you mean "must be protected" - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org From nobody Sat Sep 26 09:30:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8E1B2FC0 for ; Sat, 26 Sep 2015 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2AWuN9h4spv for ; Sat, 26 Sep 2015 09:30:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C351B2FBE for ; Sat, 26 Sep 2015 09:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V0fckWcy9yI+KoKnIaPVcFgJqclPcsgUa/liRrbC7Sk=; b=QTYUH+08KGMgmM82n4D+tzww1Lt5cUV5Mvq4LW59aWCkxlOHg7MmRHc0bBl5Ln9pBT6GFeORJeEf+gRTE8z0jwqOzYeKpYR5MZIvN9phO+jiBF0AKagoAvc/pZdDgH8jc7Uc5XkNXHpK46IYVGNIHlzKjoatTVUoSZDdMwnzyaI= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.280.20; Sat, 26 Sep 2015 16:30:34 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0280.017; Sat, 26 Sep 2015 16:30:34 +0000 From: Mike Jones To: Mike Schwartz , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] typo Thread-Index: AQHQ99nLPvAhz9O4B06pvQMS8E7eYZ5PAU5g Date: Sat, 26 Sep 2015 16:30:34 +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=Michael.Jones@microsoft.com; x-originating-ip: [50.47.89.201] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:bJlrrUfDELcl5v7bNz2iWjZiKFkkks1KYMpld/gf8/zutf8O+fvS/ZnGnWTk7QkPcQjTbPreIoBDYQaeIocuEWuDfebb5POSQev5C4FbPOR8RKMSQnpq8jT3TDKK8bUwD+mW6AEmSsD9q9jwtr+YFg==; 24:MDctBEe/Ph7WIZ/GlRgkcdZ3QeS9ZXrTKN2qNvGtGgRMZ+3nAkA6KbtMz32Fml+3oaMm9ECoHHxtc+a1EeB1bfj6YbkVDTyY/rKBLR3CtaY=; 20:aNqFiBz+yctGWQPyOEDB1y9O1NGUdUOo7VAOsNEMl2xiw6iElFosownfolt7GLzf3Zw+0JYIeXKZr2dJsy0oxw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(199003)(377454003)(11100500001)(5005710100001)(10400500002)(10090500001)(40100003)(10290500002)(8990500004)(86362001)(86612001)(5001830100001)(81156007)(4001540100001)(19580395003)(5001770100001)(19580405001)(5001860100001)(74316001)(46102003)(97736004)(68736005)(15975445007)(122556002)(76576001)(2900100001)(102836002)(5004730100002)(62966003)(77156002)(2950100001)(77096005)(92566002)(5007970100001)(87936001)(50986999)(33656002)(2501003)(5003600100002)(101416001)(66066001)(64706001)(99286002)(189998001)(105586002)(5002640100001)(5001960100002)(107886002)(54356999)(106116001)(106356001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2015 16:30:34.1964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [OAUTH-WG] typo X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 16:30:43 -0000 It took me a bit to figure out which spec this comment was about. The sent= ence Mike cited occurs in https://tools.ietf.org/html/draft-ietf-oauth-pop-= architecture-03. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Schwartz Sent: Friday, September 25, 2015 2:31 PM To: oauth@ietf.org Subject: [OAUTH-WG] typo You have a little typo in the abstract: "bearer tokens must to be protected from disclosure in transit and at rest.= " I think you mean "must be protected" - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Sep 26 09:50:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD651A00E6 for ; Sat, 26 Sep 2015 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYYpmLtqRGxt for ; Sat, 26 Sep 2015 09:50:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFFB1A00E0 for ; Sat, 26 Sep 2015 09:50:31 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8QGoTX9014405 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Sep 2015 16:50:29 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8QGoT2L021569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 26 Sep 2015 16:50:29 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8QGoSpc029409; Sat, 26 Sep 2015 16:50:28 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 26 Sep 2015 09:50:28 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Sat, 26 Sep 2015 09:50:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <97DBB1C2-66C4-4BF8-A9B3-BE20A1576350@oracle.com> References: To: Mike Jones X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Mike Schwartz , "oauth@ietf.org" Subject: Re: [OAUTH-WG] typo X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 16:50:33 -0000 Thanks. Will fix in the next update.=20 Phil > On Sep 26, 2015, at 09:30, Mike Jones wrote:= >=20 > It took me a bit to figure out which spec this comment was about. The sen= tence Mike cited occurs in https://tools.ietf.org/html/draft-ietf-oauth-pop-= architecture-03. >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Schwartz > Sent: Friday, September 25, 2015 2:31 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] typo >=20 > You have a little typo in the abstract: >=20 > "bearer tokens must to be protected from disclosure in transit and at rest= ." >=20 > I think you mean "must be protected" >=20 > - Mike >=20 > ------------------------------------- > Michael Schwartz > Gluu > Founder / CEO > mike@gluu.org >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Sep 30 03:03:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6874F1B2DCA for ; Wed, 30 Sep 2015 03:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxL_AYlg1f8l for ; Wed, 30 Sep 2015 03:03:23 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4A27C1B2DCB for ; Wed, 30 Sep 2015 03:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1443607402; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=pvc5+3oYOAQVA/tY/xfswQPoU6OT9VnZ5iZM1XwujCc=; b=prDtlPJqqSKM4/6N85IVyF1dfZcidTsbzRT77v7Ujd3g8XJ5wI8B5XC/j07EoISFFJVaQT97T6vQ1KIhYL+3umIajaFQo+O4y2iD74taCFy28efFnVQ8n7OrOfnMppuLoWWKoCPhUdH6Chdkek3Ubh4FZYvLc6y0VOI+21+pvLc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R131e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03308; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; Received: from 10.1.153.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.180) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Sep 2015 18:03:18 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 30 Sep 2015 18:03:11 +0800 From: "Kepeng Li" To: , , Message-ID: Thread-Topic: PoP document: IPR Confirmation Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3526480998_1341972" Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] PoP document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 10:03:25 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3526480998_1341972 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Mike, John and Hannes, I am working on the shepherd writeup for the PoP document: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 One item in the template requires me to indicate whether each document author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Could you please confirm? Kind Regards Kepeng --B_3526480998_1341972 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Mike, John and Hannes,
I am working on the sheph=
erd writeup for the PoP document:
<=
font face=3D"Courier">http://tools.ietf.org/html/draft-ietf-oauth-proof-of-pos=
session-04
One item in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng

= --B_3526480998_1341972-- From nobody Wed Sep 30 03:53:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCBB1B5C60 for ; Wed, 30 Sep 2015 03:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9qRzgFhr4JZ for ; Wed, 30 Sep 2015 03:53:09 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B541B5B99 for ; Wed, 30 Sep 2015 03:53:09 -0700 (PDT) Received: by qgez77 with SMTP id z77so30957818qge.1 for ; Wed, 30 Sep 2015 03:53:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=heRscVyWcg0mbVGL68V78GE4hmUZ3YR74PZmpt9rxts=; b=H/t0HaF4/RnZ2ouKCVAasqFd6ht2KARPVWJREWeD6WVnqxuABApbzdTGaMPHpCDUCu UcRp5uxcb2I5aJguIpKOyKldvCmNtFZUqWKyRcYwJchq68FXRORTV30/YK6RNEUgkSvg OzPILtHaopHFIhYRD0gqz+N1In/5y9NqkKJRtRLX3VDNesWRVJYQTSUR+UnBPKoeKWJg jgl8ruie6Bu6daQDZaWlp2nG1hOFsCHGCUa0eHyC5XKknvvAeMfIzODPU7axaBQPwtuR 4o6JBoLCIsvegIfF8TfMzx4SQ8rfRyvDT3IMpYysJSeTHiqzt3aV1j7dEsSsKw4FroQF lo8g== X-Gm-Message-State: ALoCoQn+Gi+tlmzEUlvr9rCynAWy+4TRx+C3kXK7gkzxiuHePd509WXk2RFsTV+tKMG2IBRhxliC X-Received: by 10.140.194.148 with SMTP id p142mr3691882qha.84.1443610388317; Wed, 30 Sep 2015 03:53:08 -0700 (PDT) Received: from [192.168.1.216] ([191.115.19.36]) by smtp.gmail.com with ESMTPSA id o8sm158052qko.13.2015.09.30.03.52.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Sep 2015 03:53:07 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_720BE79C-0E69-4B52-9470-65C6137099E7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Wed, 30 Sep 2015 07:51:45 -0300 Message-Id: References: To: Kepeng Li X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Michael Jones , oauth@ietf.org Subject: Re: [OAUTH-WG] PoP document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 10:53:11 -0000 --Apple-Mail=_720BE79C-0E69-4B52-9470-65C6137099E7 Content-Type: multipart/alternative; boundary="Apple-Mail=_FD14D214-2289-402F-B0D0-6C072E7AB32E" --Apple-Mail=_FD14D214-2289-402F-B0D0-6C072E7AB32E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I confirm that I know of no IPR that reads on this specification. John Bradley=E2=80=99 > On Sep 30, 2015, at 7:03 AM, Kepeng Li = wrote: >=20 > Hi Mike, John and Hannes, > I am working on the shepherd writeup for the PoP document: > http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 = > One item in the template requires me to indicate whether > each document author has confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP = 78 > and BCP 79 have already been filed. >=20 > Could you please confirm? >=20 > Kind Regards > Kepeng >=20 --Apple-Mail=_FD14D214-2289-402F-B0D0-6C072E7AB32E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I confirm that I know of no IPR that reads on this = specification.

John = Bradley=E2=80=99

On Sep 30, 2015, at 7:03 AM, = Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Hi Mike, John and = Hannes,
I =
am working on the shepherd writeup for the PoP =
document:
http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession=
-04
One item in the template =
requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng


= --Apple-Mail=_FD14D214-2289-402F-B0D0-6C072E7AB32E-- --Apple-Mail=_720BE79C-0E69-4B52-9470-65C6137099E7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA5MzAxMDUxNDVaMCMGCSqGSIb3DQEJBDEWBBRiKt3QvklH9+rYlevVDNgX L7cnFTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA7bDSu+I+e8zyUn980KVHUuuPI59+t3jutHXFz8v5/DzQJp0jUaYaw DC65stIkahzT/5eJn43IOnuDoiMYh6eIyxLu0RoMu7NlWLbCUzICMd8PBhgih1pdLfBupZxo2sjk 7jQRKhwNEBhIoATMy2/CcTjNP24hUnwRdQMxhoEWAtcY+5IDrjuXs6o0QJOqneURVWYLENkZFLMx 56j42zgS3UJTTYuPtiCoTlwwNNBVUxEYgm4SxKbYKkZf0eKM/2pojZcpBGAdHlAIFT4rB1m/llv5 Z0k8SC7i9Va3PbNduZR65tlYq4N+MdjJWh631PulSsaDHZv3BzQevJaEIC29AAAAAAAA --Apple-Mail=_720BE79C-0E69-4B52-9470-65C6137099E7-- From nobody Wed Sep 30 07:10:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F158B1A8760 for ; Wed, 30 Sep 2015 07:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-TqaHcaSEFI for ; Wed, 30 Sep 2015 07:10:56 -0700 (PDT) Received: from nm40-vm1.bullet.mail.bf1.yahoo.com (nm40-vm1.bullet.mail.bf1.yahoo.com [72.30.239.209]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A6D1A875E for ; Wed, 30 Sep 2015 07:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1443622254; bh=nHD6e0AoBzTNYoHeeWUmeSCq0TI7wRLyR48jnxSvYCM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=rfnxYRRyqonZU5ncM+PfXaaIeM3ZbsvmtO0baYhNTm9MACrseP2MRzrJSn/NTsbsGEYBhigLMob2YAgU14aIBIES5XZEQWRx4dZv+2+U/xG/GnqrAPwvyPa9cH8o2Q+AH5DZJXlFZIv/ceeYvs8zf1V32TcEAVjhSW2EKRw4QrHOFvaro+GZpOdqQH+uq56U3lWMcWH/SiukakCdLrS/pGK9FIV0fp5tGQzHrMv2Hhy+fmiiMZDV/C1p/N/w340F9Z4IiiRj4nhW8aCBtpgCAhY08Q8hPtUSZ7U6/jbT9jUnNOGlxuD0/x1uLUYjm+xiwmUNbTfLxg6/PL9BB52M2w== Received: from [98.139.214.32] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 30 Sep 2015 14:10:54 -0000 Received: from [98.139.212.241] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 30 Sep 2015 14:10:54 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 30 Sep 2015 14:10:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 805125.17086.bm@omp1050.mail.bf1.yahoo.com X-YMail-OSG: Cc_at_cVM1k6ntBtGKGXVL8m7CVBz6B5frh5qQOJsRfGpnrNyKwAOt2Dy3ISAVN 08gJavNmSS96zBStFgmI_IzYohFB91MXnG0e9yaFM6Ch8AjqZgomeyfisxpMOFlSVEXXhbge.ht9 L0_Mt5NyqlC.sOLKa3IuemDMIs4iECkwtkW1N56tEArknnVqwWLHSLiaqv3p8yw7z_3V8vhuPiXy TzJCbsMFkX_NXmO1Yuc_hHzITzRp_oCJEaD3uNKOWBIoRZKhM8ndDK7C41_Mn1.Aylyo8ZlWlX6c ME8mELoYeKajukcVT5rx0dpl7k0m0aFM43hZvY0iQICLbPbezJBrg6Sg1zNsP6QdUV0pHh21KP7e Hz9kw_n7.t4j2JpOTinnn3_cxMcR7.FvXyBvMSAzT2pqTykQYeHrWacnSXCCjHj8PW4hnu_bMqPi QakujiT7E5YHD7dbv0.L6R1H71X3JKWQSwqlW6drLq.nUoIXy.CQo1CprMhjra6Y9tMBnRGbIdH8 Imk9zjOdPHs9D3pkGSarNxd_l1NNIVvGi04v5qiu5unCTMHvhdAI- Received: by 76.13.26.109; Wed, 30 Sep 2015 14:10:54 +0000 Date: Wed, 30 Sep 2015 14:10:53 +0000 (UTC) From: Bill Mills To: John Bradley , Kepeng Li Message-ID: <1795325803.3170391.1443622253909.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3170390_1206114249.1443622253903" Archived-At: Cc: Michael Jones , "oauth@ietf.org" Subject: Re: [OAUTH-WG] PoP document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 14:10:57 -0000 ------=_Part_3170390_1206114249.1443622253903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am aware of no IPR issues for this document. Regards, -bill=20 On Wednesday, September 30, 2015 3:53 AM, John Bradley wrote: =20 I confirm that I know of no IPR that reads on this specification. John Bradley=E2=80=99 On Sep 30, 2015, at 7:03 AM, Kepeng Li wrote: Hi Mike, John and Hannes,I am working on the shepherd writeup for the PoP d= ocument:http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04O= ne item in the template requires me to indicate whether each document author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Could you please confirm? Kind RegardsKepeng _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_3170390_1206114249.1443622253903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am aware of no IPR issues for this document.

Regards,

=
-bill<= /span>



On Wednesday, September 30, 2015 3:53 A= M, John Bradley <ve7jtb@ve7jtb.com> wrote:

I confirm = that I know of no IPR that reads on this specification.

John Bradley=E2=80=99

On Sep 30, 2015, at 7:03 AM, Kep= eng Li <kepeng.lkp@alibaba-inc.com> wrote:
<= br clear=3D"none" class=3D"yiv0096462979Apple-interchange-newline">
Hi Mike, John and Hannes,
= 
I am working on the=
 shepherd writeup for the PoP document:
http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04
One i=
tem in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng


<= /div>

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

------=_Part_3170390_1206114249.1443622253903-- From nobody Wed Sep 30 07:17:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD78E1A8780 for ; Wed, 30 Sep 2015 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0bwhR8ewtTt for ; Wed, 30 Sep 2015 07:17:53 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018E61A8789 for ; Wed, 30 Sep 2015 07:17:50 -0700 (PDT) X-AuditID: 12074423-f793f6d000007fc1-6d-560bef0db6e9 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B5.A3.32705.D0FEB065; Wed, 30 Sep 2015 10:17:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t8UEHmIc000436; Wed, 30 Sep 2015 10:17:48 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t8UEHk3u008894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Sep 2015 10:17:47 -0400 To: Bill Mills , John Bradley , Kepeng Li References: <1795325803.3170391.1443622253909.JavaMail.yahoo@mail.yahoo.com> From: Justin Richer Message-ID: <560BEF09.9020106@mit.edu> Date: Wed, 30 Sep 2015 10:17:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1795325803.3170391.1443622253909.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------010008030000030106070401" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixG6nrsv7njvM4OIiaYvL84ssmp6sZbc4 +fYVm8Xqu3/ZLL51XWd2YPWY+PYji8eSJT+ZPFp3/GX3uH17I4vHrFmHmQJYo7hsUlJzMstS i/TtErgyvnzqZSuY7FHR3FTdwPhIv4uRk0NCwETi9Nc3TBC2mMSFe+vZQGwhgcVMEqtf+XYx cgHZGxklDp56zgjh3GaS6H+wihmkSljATKLz3zWwbhGBKomnMz+zQ3Q3MEq8uxkCYjMLeEgs a3wKNpVNQFVi+poWsHpeATWJFafvgtWzAMXv9qxlBbFFBWIken5tYIOoEZQ4OfMJC4jNKeAr 8XRbMyvEzDCJNzvOsUxgFJiFpGwWkhSEbStxZ+5uZghbXqJ562woW1di0bYV7MjiCxjZVjHK puRW6eYmZuYUpybrFicn5uWlFuma6eVmluilppRuYgRHiovyDsY/B5UOMQpwMCrx8L4Q4A4T Yk0sK67MPcQoycGkJMr77SVQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvo9tAOd6UxMqq1KJ8 mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd7rb4EaBYtS01Mr0jJzShDSTBycIMN5 gIYfB6nhLS5IzC3OTIfIn2JUlBLnjQFJCIAkMkrz4HpBiSzh7WHTV4ziQK8I8/4DqeIBJkG4 7ldAg5mABs/V5QIZXJKIkJJqYPRRvL3EYnlMi1TB//0pkWZuzXo/11/medZ2WoFD7/rmtFuc rzadNcuXlr96rS2+Z6+oXG9iUpbK7akfMlbLt7OlNkXeFHzm4dvE5K17wlL59o3sgs7lV91X uzq+r//SpC3VuGWJYn9d0hQmVRcfacnqCd6ztx54KfJwVUCH8E2vo8anY87HKbEUZyQaajEX FScCAAEuoGQ/AwAA Archived-At: Cc: Michael Jones , "oauth@ietf.org" Subject: Re: [OAUTH-WG] PoP document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 14:17:54 -0000 This is a multi-part message in MIME format. --------------010008030000030106070401 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I am aware of no IPR issues with this specification. -- Justin On 9/30/2015 10:10 AM, Bill Mills wrote: > I am aware of no IPR issues for this document. > > Regards, > > -bill > > > > On Wednesday, September 30, 2015 3:53 AM, John Bradley > wrote: > > > I confirm that I know of no IPR that reads on this specification. > > John Bradley’ > >> On Sep 30, 2015, at 7:03 AM, Kepeng Li > > wrote: >> >> Hi Mike, John and Hannes, >> I am working on the shepherd writeup for the PoP document: >> http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 >> >> One item in the template requires me to indicate whether each >> document author has confirmed that any and all appropriate IPR >> disclosures required for full conformance with the provisions of BCP >> 78 and BCP 79 have already been filed. Could you please confirm? Kind >> Regards >> Kepeng >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010008030000030106070401 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I am aware of no IPR issues with this specification.

 -- Justin

On 9/30/2015 10:10 AM, Bill Mills wrote:
I am aware of no IPR issues for this document.

Regards,

-bill



On Wednesday, September 30, 2015 3:53 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


I confirm that I know of no IPR that reads on this specification.

John Bradley’

On Sep 30, 2015, at 7:03 AM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Hi Mike, John and Hannes,
I am working on the shepherd writeup for the PoP document:
http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04
One item in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng



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




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

--------------010008030000030106070401-- From nobody Wed Sep 30 09:49:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCDF1A0158 for ; Wed, 30 Sep 2015 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ryugbq5CIhlV for ; Wed, 30 Sep 2015 09:49:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54ED21A00C8 for ; Wed, 30 Sep 2015 09:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BUxvjFYjgtzchNnjigfvNvEBmmATfu+7bZg7GS5Vwfk=; b=d9I7be3ZIN/FIcvLviHfmRPIl0xw+mJgSIa5jTPspUFFSeaQAV376Io+CvB4seAquxYKq3xC4J61YZKF7fILrhIQ75DiB+ZufjHI+Z+TAIQnxPycr3mvI0rpZUVJsYLF+cIn+2omzZjb9eqppY7CYv/h3bRbcUyEg6Qbbvs4v/8= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 16:49:02 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0280.021; Wed, 30 Sep 2015 16:49:02 +0000 From: Mike Jones To: Kepeng Li , "ve7jtb@ve7jtb.com" , "Hannes.Tschofenig@gmx.net" Thread-Topic: PoP document: IPR Confirmation Thread-Index: AQHQ+2dA+aByBKz4r0aEiqM/1NRp1J5VSQMH Date: Wed, 30 Sep 2015 16:49: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=Michael.Jones@microsoft.com; x-originating-ip: [50.47.89.201] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:fWDuK3P0IhKw8wWhCT8BatloD7HP9gfDVdmH8C0zgZngNk6XxP97lxbDkteP8h41kCv+mBTfz8voxc04hO6wbY0zcl1w40Yd8NdL1+ZfEGIm/uj1YXsxAnwzb0nmHZl2I4bVcuywmwXDJlYGKd+Amg==; 24:nl+8qiOpsrFZJvoSX9Iec7Rs4RKMV5I0hZ3OHT4uVUtsFAAI10GbWeitkrmLWaep5QHR6AIBqMrQzkj+N4sR72r3WqYASa6M2nlnBRjbc4c=; 20:oTEBahI++OB463qMbupkJwMJ0ztoCnT5hU1QcYlnP1tCp7zrXCyQGPdYUxxbvvRqxh3Fr/AW7BQrYWxEqraymg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(52604005)(377454003)(71364002)(19580395003)(87936001)(5001830100001)(19580405001)(74316001)(66066001)(86362001)(68736005)(64706001)(5004730100002)(11100500001)(5007970100001)(5003600100002)(15975445007)(2501003)(2201001)(40100003)(77096005)(102836002)(122556002)(10290500002)(97736004)(5001770100001)(4001540100001)(5001860100001)(92566002)(12110500001)(10400500002)(81156007)(5001960100002)(5008740100001)(5002640100001)(106356001)(189998001)(8990500004)(33656002)(54356999)(10090500001)(46102003)(86612001)(5005710100001)(16236675004)(5001920100001)(50986999)(76176999)(62966003)(101416001)(19617315012)(2950100001)(2900100001)(99286002)(105586002)(77156002)(106116001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4428828D13B35D3A85CB3A8F54D0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 16:49:02.1339 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] PoP document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 16:49:26 -0000 --_000_BY2PR03MB4428828D13B35D3A85CB3A8F54D0BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Thanks for doing this, Kepeng. I am aware of no IPR that pertains to this s= pecification. -- Mike ________________________________ From: Kepeng Li Sent: =FD9/=FD30/=FD2015 3:03 AM To: Mike Jones; ve7jtb@ve7jtb.com; Hannes.Tschofenig@gmx.net Cc: oauth@ietf.org Subject: PoP document: IPR Confirmation Hi Mike, John and Hannes, I am working on the shepherd writeup for the PoP document: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 One item in the template requires me to indicate whether each document author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Could you please confirm? Kind Regards Kepeng --_000_BY2PR03MB4428828D13B35D3A85CB3A8F54D0BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Thanks for do= ing this, Kepeng. I am aware of no IPR that pertains to this specification.=

-- Mike
From: Kepeng Li
Sent: =FD9/= =FD30/=FD2015 3:03 AM
To: Mike Jones; ve7jtb@ve7jtb.com; Hannes.Tschofenig@gmx.net
Cc: oauth@ietf.org
Subject: PoP d= ocument: IPR Confirmation

Hi Mike, John and Hann= es,
I am working on the shepherd writeup=
 for the PoP document:
http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04
One item in the =
template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng

--_000_BY2PR03MB4428828D13B35D3A85CB3A8F54D0BY2PR03MB442namprd_--