From nobody Fri Sep 2 12:16:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6E812B00C for ; Fri, 2 Sep 2016 12:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZz4ejqInIyy for ; Fri, 2 Sep 2016 12:16:03 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD6612B029 for ; Fri, 2 Sep 2016 12:16:02 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id z190so130092036qkc.0 for ; Fri, 02 Sep 2016 12:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5mugocBPyZkgm4+3/RrVJCIn/Mq7a8a1534hMZfgdxs=; b=knJXqOXt7RiXpUk/TYnVO1576cBZyOc6r8UQ/oyHgDNNc2ZGINrCdpk0idolyJEWA/ 7ONaJXAsNbyhk33BV82SPol6JBHt3zHzUYXKAoQJBziM9YzfdJ21g3756C8G3h5PlQ2E JeCTTfxDyDn2z1HbMEoeNzmbILcmf1iTfxS65tJv9N9LxVJRtuhGm+I9VcQU9auIvLVE mDtRwR7LtBCOs6tygH+u3/MJcQGbYWIuXfDXuH0W1rPhBOvHVjLKR8XGnbvCtaaL0e3R JQCZImbCOJc5H8uMi06o0n0h/4rJ/0i6TJ0HND5Ar0nLBxfKm2z90s4wTcr1tWbqhzJJ AZ/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5mugocBPyZkgm4+3/RrVJCIn/Mq7a8a1534hMZfgdxs=; b=Vbdvk7yqKiBhx9TDml2zzG/sBBV6nr7RfGIMWpnAGMzbWK+M4Wm1DDbNl+6lgnRq0L 2o0Xcq/OoiqGZ2LDmAp6SNPLfR0tkU5HhJzxl6Wg5c5IkSqBRJNoRN1PUz7B3Y7yadeU 3tyACfBWG4MgpBCq1+THtlxv/r6J5a6zXYdMACvUwugWXJB/2mXM57k0jvvjrs7Wk8dY rKmsl73gTcv7IODXXFVYQCEfct4EeFOR5PUaWeV/FCdFXekc+woKB4DFM+7AfabyM74g QKBvlckiTOqmx4pS+AdPiUhPnJPhy1CvKGpiISicJVXQUeX4SxxV17JFGcavWR2W+TSN /sbg== X-Gm-Message-State: AE9vXwN+vd2nt1kZ+4AH0frQqO2QlCF9JQDdAKlFVKlgiGseifilSzH7XHgmXiv9G9g6gmVS X-Received: by 10.55.183.6 with SMTP id h6mr26419855qkf.192.1472843761308; Fri, 02 Sep 2016 12:16:01 -0700 (PDT) Received: from [192.168.8.100] ([181.201.166.82]) by smtp.gmail.com with ESMTPSA id d38sm6783730qte.17.2016.09.02.12.15.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Sep 2016 12:16:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8FBF360E-84E1-4F9E-B84E-F7A23C5D5CA3" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 2 Sep 2016 16:15:55 -0300 Message-Id: <464ABFED-9C4C-4356-B01F-0BD2B398FD0E@ve7jtb.com> References: To: Adam Lewis X-Mailer: Apple Mail (2.3124) Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Question on draft-ietf-oauth-token-exchange-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 19:16:07 -0000 --Apple-Mail=_8FBF360E-84E1-4F9E-B84E-F7A23C5D5CA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes one of the reasons for not pushing ahead with AC/DC despite the cool = name was that Token Exchange will provide a more general approach to = solve some of the same uses cases.=20 If we did AC/DC for the specific Connect use case then we would still = have other gaps that would need another spec and people would be more = confused. The more general Token Exchange will be a better long term solution. John B. > On Apr 13, 2016, at 9:23 AM, Adam Lewis = wrote: >=20 > Hi Brian, >=20 > Your explanation is helpful, makes sense now. =20 >=20 > In fact, this makes things very interesting for me because it could = provide a round-about way to do an ac/dc like flow where a client C = whose AS1 is in security domain 1 can swap an access token from AS1 for = a JWT to present to AS2 via a JWT grant type, in exchange for an access = token from AS2 to use at RS2. >=20 > I've been bumbed out about ac/dc losing steam because it provided a = very elegant solution for some of my critical use cases, but token = exchange is shaping up to indirectly provide the same functionality. = Awesome :-) >=20 >=20 >=20 > -adam >=20 > On Mon, Apr 11, 2016 at 3:26 PM, Brian Campbell = > wrote: > The intent is that urn:ietf:params:oauth:token-type:access_token be an = indicator that the token is a typical OAuth access token issued by the = AS in question, opaque to the client, and usable the same manner as any = other access token obtained from that AS (it could well be a JWT but the = client isn't and needn't be aware of that fact). Whereas = urn:ietf:params:oauth:token-type:jwt is to indicate that a JWT = specifically is being requested or sent (perhaps in a cross-domain use = case to get an access token from a different AS like is facilitated by = RFC 7523).=20 >=20 > Is that helpful at all? >=20 > I agree that it can be confusing. But it's representative of the kinds = of tokens and their usages out there now. So, needs to be allowed. I'd = welcome ideas about how the language could be improved to help alleviate = some of the confusion though.=20 >=20 > On Mon, Apr 11, 2016 at 7:25 AM, Adam Lewis = > wrote: > Hi, >=20 > There are multiple places in draft-ietf-oauth-token-exchange-04 where = a differentiation seems to be drawn between 'access_token' and 'jwt' ... = for example in section 2.2.1. when discussing the issued_token_type, it = states: >=20 > a value of "urn:ietf:params:oauth:token-type:access_token" = indicates=20 > that the issued token is an access token and a value of > "urn:ietf:params:oauth:token-type:jwt" indicates that it is a = JWT. >=20 > This is confusing to me because an access token represents a delegated = authorization decision, whereas JWT is a token *format*. An access = token could easily be a JWT (and in many deployments, they are). =20 >=20 > So why the desire to differentiate, and what does the differentiation = mean? >=20 >=20 > tx! > adam >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8FBF360E-84E1-4F9E-B84E-F7A23C5D5CA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes one of the reasons for not pushing ahead with AC/DC = despite the cool name was that Token Exchange will provide a more = general approach to solve some of the same uses cases. 

If we did AC/DC for the = specific Connect use case then we would still have other gaps that would = need another spec and people would be more confused.

The more general Token = Exchange will be a better long term solution.

John B.



On = Apr 13, 2016, at 9:23 AM, Adam Lewis <Adam.Lewis@motorolasolutions.com> wrote:

Hi Brian,

Your explanation is helpful, makes = sense now.  

In fact, this makes things very interesting for me because it = could provide a round-about way to do an ac/dc like flow where a client = C whose AS1 is in security domain 1 can swap an access token from AS1 = for a JWT to present to AS2 via a JWT grant type, in exchange for an = access token from AS2 to use at RS2.

I've been bumbed out about ac/dc losing = steam because it provided a very elegant solution for some of my = critical use cases, but token exchange is shaping up to indirectly = provide the same functionality.  Awesome :-)

-adam

On Mon, = Apr 11, 2016 at 3:26 PM, Brian Campbell <bcampbell@pingidentity.com> = wrote:
The intent is = that urn:ietf:params:oauth:token-type:access_token be an indicator that = the token is a typical OAuth access token issued by the AS in question, = opaque to the client, and usable the same manner as any other access = token obtained from that AS (it could well be a JWT but the client isn't = and needn't be aware of that fact). Whereas = urn:ietf:params:oauth:token-type:jwt is to indicate that a JWT = specifically is being requested or sent (perhaps in a cross-domain use = case to get an access token from a different AS like is facilitated by = RFC 7523).

Is that helpful at = all?

I agree that it can be = confusing. But it's representative of the kinds of tokens and their = usages out there now. So, needs to be allowed. I'd welcome ideas about = how the language could be improved to help alleviate some of the = confusion though.

On Mon, Apr 11, 2016 at 7:25 AM, Adam Lewis = <adam.lewis@motorolasolutions.com> wrote:
Hi,

There are multiple = places in draft-ietf-oauth-token-exchange-04 where a = differentiation seems to be drawn between 'access_token' and 'jwt' ... = for example in section 2.2.1. when discussing the issued_token_type, it = states:

      a value of =
"urn:ietf:params:oauth:token-type:access_token" =
indicates 
      that the issued token is an =
access token and a value of
      "urn:ietf:params:oauth:token-type:jwt" indicates that it is a =
JWT.

This=
 is confusing to me because an access token represents a delegated =
authorization decision, whereas JWT is a token *format*.  An =
access token could easily be a JWT (and in many deployments, they are). =
 

So why the desire to differentiate, =
and what does the differentiation mean?


tx!
adam

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



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

= --Apple-Mail=_8FBF360E-84E1-4F9E-B84E-F7A23C5D5CA3-- From nobody Fri Sep 2 16:20:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8706E12D5A2 for ; Fri, 2 Sep 2016 16:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XD5YhpuNbUk for ; Fri, 2 Sep 2016 16:20:21 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8846A12D59B for ; Fri, 2 Sep 2016 16:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C5GqR3+KeQ7aGPNxKUqbST82iQQHT0cG+pDMun4IUdQ=; b=ER1YjE37pKhH0ngnulUEsj7GBN4OLZA1YxDn4naZ05/Bb1MQNihprYOcK+lCFNtIFrqXQA1Wn68R/1ailUilN7PUpG3gJFloySfALgRkVBGIV6JM8vnA9TulRAKE6LfdCXSfToOGq1X79G65e7kMT65Od6Z/Cr33xqETH9Bi944= Received: from DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) by DM2PR0301MB0639.namprd03.prod.outlook.com (10.160.96.13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Fri, 2 Sep 2016 23:20:20 +0000 Received: from DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) by DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) with mapi id 15.01.0599.010; Fri, 2 Sep 2016 23:20:20 +0000 From: Mike Jones To: Vladimir Dzhuvinov , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values" Thread-Index: AQHR6BmLWg7xtcsvLkWj5Ise9esmKaBnDslw Date: Fri, 2 Sep 2016 23:20:19 +0000 Message-ID: References: <578CE7F4.4080600@gmx.net> <8b9dd6a2-d7fa-fe92-f6d4-83044c574167@connect2id.com> In-Reply-To: <8b9dd6a2-d7fa-fe92-f6d4-83044c574167@connect2id.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: [2001:4898:80e8:e::650] x-ms-office365-filtering-correlation-id: 6a542d5a-90d2-45cc-eb83-08d3d387b510 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0639; 6:yrHG1WxCF4qR5RS6Ztlk5u7MczttDSJZWd2UcfVvvhCRMhPaE4YWtdl494a0lrNpyTZExVU2CTTHdAhafRLmgKILps0EuNuSMxd+iyqvxuEuLodcH3Id9Ggu5boj/595KTv7+I3C1hWpDk+1T68fxyeaULDE/0PXZxEL66ZcftvZWfvq+ucT7K+47ifelqtT8tByGz1r59tKTnKXpLjWQUBQWLNn980B/Kav3QmH4WgPiWHZZ8K8h6xdC7TO3EfifeGKBThHXd9dHunpRut/NSIav0/hkrYli/H5wDbYod9vtvBD/8q2LqaRFUg20srRD2LHxkIDkjbFZFLIoT5w1g==; 5:Td/2eJwAlJlA75bqttRWhHdFqNAJitvekJqWWh/0D9f12ey5e0KX+X956EFWgdDLDdhr9mVyZOwBgXtlQJcFgDSKdPjA/m9SLnBbblh/4obar1+jaGiQvsIaXfbFZCU9rFg5HUggo71LteLHGJ9myg==; 24:ayIEq94LlIM7CpSS6rlAmln8wDQzdn8MwcdkQM7WOc+e/JeGriSogzz+i83QpvIDaPNJTU0+5DOCPkYHaCR11Vy9qExlIacYmfrlhHIHWls=; 7:n1VayLGjjTcBxHNG3bEE2k/VshzPj2a4CGmb4ldO5wde+advnXx3LPoruUgiRLArhNAQgSzMu/ISnuubXPZ2Z6aZthVyElj3O+p295YH5h0ydPhKfStkSS5oGn2EwdtOXqWf7fYorL1UoiB52zK6rFjqt5YAiJWJRSAxGjZi+YgChv5e7P98ksU1TdSptXqJMUJ3We6S1WBkpJmdNu72nSb9VoiehnHjmHGb+8ojwDdQdFE5wVHCyEKdE7qREs+W x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0639; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0639; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(53754006)(13464003)(199003)(43784003)(189002)(24454002)(10090500001)(86362001)(77096005)(74316002)(15975445007)(5660300001)(122556002)(106116001)(105586002)(87936001)(102836003)(6116002)(586003)(10400500002)(33656002)(5005710100001)(8990500004)(11100500001)(19580395003)(10290500002)(97736004)(107886002)(106356001)(5001770100001)(54356999)(76176999)(50986999)(3280700002)(3660700001)(7736002)(8936002)(92566002)(68736007)(2906002)(9686002)(86612001)(7696003)(81166006)(101416001)(189998001)(99286002)(2950100001)(2900100001)(8676002)(305945005)(5002640100001)(19580405001)(81156014)(7846002)(76576001)(2501003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0639; H:DM2PR0301MB0637.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:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2016 23:20:19.9301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0639 Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 23:20:23 -0000 Thanks for your question, Vladimir. No, there is not currently an X.509-sp= ecific value defined. However, there are these related values: hwk Proof-of-possession (PoP) of a hardware-secured key. See Appendix C of [RFC4211] for a discussion on PoP. swk Proof-of-possession (PoP) of a software-secured key. See Appendix C of [RFC4211] for a discussion on PoP. Given that x.509 authentication is PoP authentication, these might apply, d= epending upon your use case. Are you using an X.509 "amr" value in practic= e? Remember that even if such a value isn't already in use now, if it is e= ver need in the future, it can always be added later via the registry estab= lished by this specification. Thanks again, -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir Dzhuvinov Sent: Wednesday, July 27, 2016 8:14 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Method R= eference Values" On 18/07/16 17:30, Hannes Tschofenig wrote: > Hi all, > > this is a Last Call for comments on the "Authentication Method=20 > Reference Values" specification. > > The document can be found here: > https://tools.ietf.org/html/draft-ietf-oauth-amr-values-01 > > Please have your comments in no later than August 1st. Thanks Hannes. Do we have an "amr" value for x.509 certificate based authentication? > Ciao > Hannes & Derek > -- Vladimir Dzhuvinov From nobody Fri Sep 2 16:55:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46EE12B039 for ; Fri, 2 Sep 2016 16:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBf-7bthOlrc for ; Fri, 2 Sep 2016 16:55:23 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0110.outbound.protection.outlook.com [104.47.33.110]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F293212B005 for ; Fri, 2 Sep 2016 16:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KEEs0mDhfDd75cNkECgPstp/RehzW4K50EhbNJTOnk0=; b=KGjy6v7sp2EsRdtdu3gR8KUUn8QRTtO8OZKLOY9j9HxP30ShbA72JwwJUK6plw6tljrdVgWEYXZmPBcdhYhAvfoDVARNijlw7+WGY2PwFewN3XmMLU4dyciJQCS2beb67ailP+k3klTgSwmuXu0JlQMnUIUOhd6d/5uGyIAHlHo= Received: from DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) by DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Fri, 2 Sep 2016 23:55:21 +0000 Received: from DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) by DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) with mapi id 15.01.0599.010; Fri, 2 Sep 2016 23:55:21 +0000 From: Mike Jones To: William Denniss , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values" Thread-Index: AQHR41COQedBclOgAkWSNv4UsdlfSqBnF93A Date: Fri, 2 Sep 2016 23:55:20 +0000 Message-ID: References: <578CE7F4.4080600@gmx.net> 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: [2001:4898:80e8:e::650] x-ms-office365-filtering-correlation-id: bd7a16da-7ff4-485a-f8d5-08d3d38c9949 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0637; 6:IFSKBjSzGbB8HN9vEPVZGY1QKJx2Xs9ojt2hxvujc3bMO1XmCMH5DnsS4n0AadN6qQurJGNlndDTLi+0uu24FGVVp9gNEBv0KEYiKPkS4+dIVhiD80+MkZ76R3sSz1E32q0pYo0E2gYpLl5bbdVEGUZ/g/NPvnfYhlaxZlkA5/dT+thm0ID4QtYwOYMMiP5Vmtk4QWF9h61KjkbAcu1diHb2tg5dnN/5cj2pSqbQdPIL0nAlohNAQ/2gxC40mDqfqWJRpkZvxwnhXjsBf5igOU8tc+kyKgGIlFeALx+LefizuSkpWeee2otYxoqRS9WgBZF44GT+cpH3Of7ep3ICIg==; 5:Mx3ijBkCxltSt/oeZoJ61AiY11i89QnB2ykJfRedYmxS0B0rv2yURAQSZgKF1pcnCG7mDHflb7F+ElSd5mVxrgA+R9uwmJAjPYjvwEhGERdDPQpFUQPKQ1OSoLftk15UYQ0gM0svX+5pt7cJv03w9Q==; 24:lBTy8rIP29wH911Q0kg7kgKNfR8w6ZBWYsAIZbsfL8FTWIOqMexRr+L0NRLvGC8uxarWB933gMAboB7ecMGQj5ZBNGKp+yM/9InVjyL2o7M=; 7:uM8+kKaMxaYb7IFVClT5K/+wqdGzCvOsHJlccol1j8bllqYTk9w3nejXi5fsvEEosDEa6flM7TtAAIKBOJSWvRI9gwyy0qVvVN9zxRp+72WgsFNXKHpc7wxMUxe8n3gQAYiaLPr7jvdvJ8b0INLGpcuODxBpOJ80FtBJHM695O+w0/6+JtvUWleiKn3aXLJ+d1tI+OSZrl+RaC45a5eQdKhV7FgOAofuEk8Qi/MFweL13+HjRSmTveVDI8VT7o49 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0637; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(248736688235697)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0637; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0637; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(43784003)(189002)(24454002)(53754006)(377454003)(199003)(10290500002)(76576001)(11100500001)(105586002)(5001770100001)(19609705001)(4326007)(99286002)(2950100001)(97736004)(92566002)(19580405001)(189998001)(2900100001)(5660300001)(77096005)(15975445007)(8990500004)(87936001)(10400500002)(106116001)(19617315012)(551544002)(5005710100001)(9686002)(106356001)(19580395003)(2906002)(8936002)(16236675004)(54356999)(586003)(68736007)(10090500001)(3660700001)(86612001)(76176999)(50986999)(6116002)(122556002)(19625215002)(7696003)(7846002)(7736002)(19300405004)(81166006)(33656002)(86362001)(102836003)(81156014)(101416001)(8676002)(3280700002)(5002640100001)(790700001)(7906003)(74316002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0637; H:DM2PR0301MB0637.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0637DCAAB49864F38B6CE60CF5E50DM2PR0301MB0637_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2016 23:55:20.6803 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0637 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 23:55:26 -0000 --_000_DM2PR0301MB0637DCAAB49864F38B6CE60CF5E50DM2PR0301MB0637_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJldmlldywgV2lsbGlhbS4gIERyYWZ0IC0wMiB3aWxsIGFkZHJlc3Mg dGhlc2UgY29tbWVudHMgYXMgZm9sbG93czoNCg0KMS4gIEFkZGVkIHNlY3Rpb24gbnVtYmVyLCBh cyBzdWdnZXN0ZWQuDQoNCjIuICBNb3ZlZCBjb3B5IG9mIOKAnGFtcuKAnSBkZWZpbml0aW9uIGlu dG8gSW50cm9kdWN0aW9uLCBzZXBhcmF0aW5nIGl0IGZyb20gdGhlIFZhbHVlcyBzZWN0aW9uLiAg SSBhZ3JlZSB0aGF0IHRoYXQgbWFrZXMgdGhlIHNwZWNpZmljYXRpb24gbW9yZSByZWFkYWJsZS4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdpbGxpYW0gRGVubmlz cw0KU2VudDogVGh1cnNkYXksIEp1bHkgMjEsIDIwMTYgNjowNCBBTQ0KVG86IEhhbm5lcyBUc2No b2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pg0KQ2M6IG9hdXRoQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiAiQXV0aGVu dGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMiDQoNCkknbSBnbGFkIHRvIHNlZSB0aGlz IGRvY3VtZW50IGluIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLiAgVGhlIGFtciB2YWx1ZXMgbXkg dGVhbSBpcyB1c2luZyBpbiBvdXIgaW1wbGVtZW50YXRpb24gYXJlIGluY2x1ZGVkLg0KDQpJIGhh dmUgcmV2aWV3ZWQgdGhlIDAxIHZlcnNpb24gb2YgdGhpcyBkcmFmdCwgYW5kIEkgYmVsaWV2ZSBp cyByZWFkeSB0byBiZWNvbWUgYW4gUkZDLg0KDQpJIGhhdmUgb25seSB0d28gbWlub3IgZWRpdG9y aWFsIGNvbW1lbnRzOg0KDQoxLg0KV2hlcmUgd2UgcmVmZXJlbmNlIHRoZSBjbGFpbSBpbiBDb25u ZWN0IChhbXIgZHJhZnQgc2VjdGlvbiAyKSwgd2Ugc2hvdWxkIGFsc28gc3RhdGUgdGhlIHNwZWNp ZmljIHNlY3Rpb24sIGkuZS4gImlzIGRlZmluZWQgYnkgU2VjdGlvbiAyLjAgb2YgdGhlIE9wZW5J RCBDb25uZWN0IENvcmUgMS4wIHNwZWNpZmljYXRpb24iLg0KDQoyLg0KSSBmb3VuZCB0aGUganV4 dGFwb3NpdGlvbiBvZiB0aGUgYW1yIGNsYWltIGRlZmluaXRpb24gYW5kIHRoZSB2YWx1ZXMgYSBs aXR0bGUgY29uZnVzaW5nLCBhcyB0aGUgZm9ybWVyIGlzIHJlLXN0YXRpbmcgYW4gZXhpc3Rpbmcg ZGVmaW5pdGlvbiB3aGlsZSB0aGUgbGF0dGVyIGlzIG5ldyBtYXRlcmlhbCBwcm92aWRlZCBieSB0 aGlzIHNwZWMuIEknbSBnbGFkIHRvIHNlZSB0aGUgY2xhaW0gZGVmaW5pdGlvbiBpbiB0aGlzIGRy YWZ0LCBhcyBpdCBoZWxwcyB0byBwcm92aWRlIGNvbnRleHQsIGJ1dCBJIG1pZ2h0IHJlc3RydWN0 dXJlIGludG8gdHdvIHNlY3Rpb25zLCBhcyBiZWxvdyAoZ3JlZW4gdGV4dCBhZGRlZC9jaGFuZ2Vk KS4gIElmIHJlc3RydWN0dXJlZCBpbiB0aGlzIHdheSwgc2VjdGlvbiAyIHdvdWxkIHByb3ZpZGUg dGhlIGJhY2tncm91bmQgYW5kIHNlY3Rpb24gMyB3b3VsZCBwcm92aWRlIHRoZSBuZXcgbWF0ZXJp YWwsIG1ha2luZyBpdCBlYXNpZXIgdG8gcmVmZXJlbmNlIGZyb20gb3RoZXIgZG9jdW1lbnRzLg0K DQotLS0NCg0KMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1h bXItdmFsdWVzLTAxI3NlY3Rpb24tMj4uICBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNl IENsYWltDQoNCg0KDQoNCg0KICAgVGhlICJhbXIiIChBdXRoZW50aWNhdGlvbiBNZXRob2RzIFJl ZmVyZW5jZXMpIGNsYWltIGlzIGRlZmluZWQgYnkgc2VjdGlvbiAyLjAgb2YgdGhlDQoNCiAgIE9w ZW5JRCBDb25uZWN0IENvcmUgMS4wIHNwZWNpZmljYXRpb24gW09wZW5JRC5Db3JlPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDEjcmVmLU9w ZW5JRC5Db3JlPl0gYXMgZm9sbG93czoNCg0KDQoNCiAgIGFtcg0KDQogICAgICBPUFRJT05BTC4g IEF1dGhlbnRpY2F0aW9uIE1ldGhvZHMgUmVmZXJlbmNlcy4gIEpTT04gYXJyYXkgb2YNCg0KICAg ICAgc3RyaW5ncyB0aGF0IGFyZSBpZGVudGlmaWVycyBmb3IgYXV0aGVudGljYXRpb24gbWV0aG9k cyB1c2VkIGluDQoNCiAgICAgIHRoZSBhdXRoZW50aWNhdGlvbi4gIEZvciBpbnN0YW5jZSwgdmFs dWVzIG1pZ2h0IGluZGljYXRlIHRoYXQgYm90aA0KDQogICAgICBwYXNzd29yZCBhbmQgT1RQIGF1 dGhlbnRpY2F0aW9uIG1ldGhvZHMgd2VyZSB1c2VkLiAgVGhlIGRlZmluaXRpb24NCg0KICAgICAg b2YgcGFydGljdWxhciB2YWx1ZXMgdG8gYmUgdXNlZCBpbiB0aGUgImFtciIgQ2xhaW0gaXMgYmV5 b25kIHRoZQ0KDQogICAgICBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uICBQYXJ0aWVzIHVz aW5nIHRoaXMgY2xhaW0gd2lsbCBuZWVkDQoNCiAgICAgIHRvIGFncmVlIHVwb24gdGhlIG1lYW5p bmdzIG9mIHRoZSB2YWx1ZXMgdXNlZCwgd2hpY2ggbWF5IGJlDQoNCiAgICAgIGNvbnRleHQtc3Bl Y2lmaWMuICBUaGUgImFtciIgdmFsdWUgaXMgYW4gYXJyYXkgb2YgY2FzZSBzZW5zaXRpdmUNCg0K ICAgICAgc3RyaW5ncy4NCg0KDQoNCiAgIE9wZW5JRCBDb25uZWN0IGRvZXMgbm90IHNwZWNpZnkg YW55IHBhcnRpY3VsYXINCg0KICAgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSB2YWx1 ZXMgdG8gYmUgdXNlZCBpbiB0aGUgImFtciIgY2xhaW0uDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBlc3RhYmxpc2hlcyBhIHJlZ2lzdHJ5IGZvciB0aGVzZSB2YWx1ZXMgYW5kIGRlZmluZXMgYSBz dGFydGluZyBsaXN0Lg0KDQoNCg0KMy4gIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2Ug VmFsdWVzDQoNCg0KDQoNCg0KICAgVGhlIGZvbGxvd2luZyBpcyBhIGxpc3Qgb2YgQXV0aGVudGlj YXRpb24gTWV0aG9kIFJlZmVyZW5jZSB2YWx1ZXMNCg0KICAgZGVmaW5lZCBieSB0aGlzIHNwZWNp ZmljYXRpb246DQoNCk9uIE1vbiwgSnVsIDE4LCAyMDE2IGF0IDQ6MzAgUE0sIEhhbm5lcyBUc2No b2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0Pj4gd3JvdGU6DQpIaSBhbGwsDQoNCnRoaXMgaXMgYSBMYXN0IENhbGwgZm9yIGNv bW1lbnRzIG9uIHRoZSAiQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZQ0KVmFsdWVzIiBz cGVjaWZpY2F0aW9uLg0KDQpUaGUgZG9jdW1lbnQgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTAxDQoNClBs ZWFzZSBoYXZlIHlvdXIgY29tbWVudHMgaW4gbm8gbGF0ZXIgdGhhbiBBdWd1c3QgMXN0Lg0KDQpD aWFvDQpIYW5uZXMgJiBEZXJlaw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCg== --_000_DM2PR0301MB0637DCAAB49864F38B6CE60CF5E50DM2PR0301MB0637_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdo dCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMkU3NEI1O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1z b25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5nbWFpbC1oMg0KCXttc28tc3R5bGUtbmFtZTpn bWFpbC1oMjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYw Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29y YXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhbmtzIGZvciB5b3VyIHJl dmlldywgV2lsbGlhbS4mbmJzcDsgRHJhZnQgLTAyIHdpbGwgYWRkcmVzcyB0aGVzZSBjb21tZW50 cyBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ MS4mbmJzcDsgQWRkZWQgc2VjdGlvbiBudW1iZXIsIGFzIHN1Z2dlc3RlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjIuJm5ic3A7IE1vdmVkIGNvcHkgb2Yg4oCc YW1y4oCdIGRlZmluaXRpb24gaW50byBJbnRyb2R1Y3Rpb24sIHNlcGFyYXRpbmcgaXQgZnJvbSB0 aGUgVmFsdWVzIHNlY3Rpb24uJm5ic3A7IEkgYWdyZWUgdGhhdCB0aGF0IG1ha2VzIHRoZSBzcGVj aWZpY2F0aW9uIG1vcmUgcmVhZGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGFn YWluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldpbGxpYW0gRGVubmlzczxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSnVseSAyMSwgMjAxNiA2OjA0IEFNPGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNj aG9mZW5pZyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+ IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFdvcmtp bmcgR3JvdXAgTGFzdCBDYWxsIG9uICZxdW90O0F1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVu Y2UgVmFsdWVzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdt IGdsYWQgdG8gc2VlIHRoaXMgZG9jdW1lbnQgaW4gd29ya2luZyBncm91cCBsYXN0IGNhbGwuJm5i c3A7IFRoZSBhbXIgdmFsdWVzIG15IHRlYW0gaXMgdXNpbmcgaW4gb3VyIGltcGxlbWVudGF0aW9u IGFyZSBpbmNsdWRlZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGhhdmUgcmV2aWV3ZWQgdGhlIDAxIHZlcnNpb24gb2YgdGhpcyBkcmFmdCwg YW5kIEkgYmVsaWV2ZSBpcyByZWFkeSB0byBiZWNvbWUgYW4gUkZDLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBvbmx5 IHR3byBtaW5vciBlZGl0b3JpYWwgY29tbWVudHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlcmUgd2UgcmVmZXJlbmNlIHRoZSBj bGFpbSBpbiBDb25uZWN0IChhbXIgZHJhZnQgc2VjdGlvbiAyKSwgd2Ugc2hvdWxkIGFsc28gc3Rh dGUgdGhlIHNwZWNpZmljIHNlY3Rpb24sIGkuZS4gJnF1b3Q7aXMgZGVmaW5lZCBieSBTZWN0aW9u IDIuMCBvZiB0aGUgT3BlbklEIENvbm5lY3QgQ29yZSAxLjAgc3BlY2lmaWNhdGlvbiZxdW90Oy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBmb3VuZCB0aGUganV4dGFwb3NpdGlvbiBvZiB0aGUgYW1yIGNsYWltIGRlZmluaXRpb24g YW5kIHRoZSB2YWx1ZXMgYSBsaXR0bGUgY29uZnVzaW5nLCBhcyB0aGUgZm9ybWVyIGlzIHJlLXN0 YXRpbmcgYW4gZXhpc3RpbmcgZGVmaW5pdGlvbiB3aGlsZSB0aGUgbGF0dGVyIGlzIG5ldyBtYXRl cmlhbCBwcm92aWRlZCBieSB0aGlzIHNwZWMuIEknbSBnbGFkIHRvIHNlZSB0aGUgY2xhaW0gZGVm aW5pdGlvbiBpbg0KIHRoaXMgZHJhZnQsIGFzIGl0IGhlbHBzIHRvIHByb3ZpZGUgY29udGV4dCwg YnV0IEkgbWlnaHQgcmVzdHJ1Y3R1cmUgaW50byB0d28gc2VjdGlvbnMsIGFzIGJlbG93IChncmVl biB0ZXh0IGFkZGVkL2NoYW5nZWQpLiZuYnNwOyBJZiByZXN0cnVjdHVyZWQgaW4gdGhpcyB3YXks IHNlY3Rpb24gMiB3b3VsZCBwcm92aWRlIHRoZSBiYWNrZ3JvdW5kIGFuZCBzZWN0aW9uIDMgd291 bGQgcHJvdmlkZSB0aGUgbmV3IG1hdGVyaWFsLCBtYWtpbmcgaXQgZWFzaWVyDQogdG8gcmVmZXJl bmNlIGZyb20gb3RoZXIgZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGgyIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlcy0wMSNzZWN0aW9u LTIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj4yPC9zcGFuPjwv YT48YSBuYW1lPSJzZWN0aW9uLTIiPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LiZuYnNwOw0K IEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgQ2xhaW08bzpwPjwvbzpwPjwvc3Bhbj48 L2gyPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBUaGUgJnF1b3Q7YW1yJnF1b3Q7IChBdXRoZW50aWNhdGlvbiBNZXRob2RzIFJlZmVyZW5j ZXMpIGNsYWltIGlzIGRlZmluZWQgYnkgPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3 NjFEIj5zZWN0aW9uIDIuMCBvZiB0aGU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IE9wZW5JRCBDb25uZWN0IENvcmUgMS4wIHNwZWNpZmljYXRpb24gWzwv c3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1hbXItdmFsdWVzLTAxI3JlZi1PcGVuSUQuQ29yZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5PcGVuSUQuQ29yZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5dIGFzIGZv bGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFtcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBPUFRJT05BTC4mbmJzcDsgQXV0aGVudGljYXRpb24gTWV0aG9kcyBSZWZlcmVuY2VzLiZuYnNw OyBKU09OIGFycmF5IG9mPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZ3MgdGhh dCBhcmUgaWRlbnRpZmllcnMgZm9yIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgdXNlZCBpbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgYXV0aGVudGljYXRpb24uJm5ic3A7IEZvciBp bnN0YW5jZSwgdmFsdWVzIG1pZ2h0IGluZGljYXRlIHRoYXQgYm90aDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBwYXNzd29yZCBhbmQgT1RQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgd2Vy ZSB1c2VkLiZuYnNwOyBUaGUgZGVmaW5pdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBvZiBwYXJ0aWN1bGFyIHZhbHVlcyB0byBiZSB1c2VkIGluIHRoZSAmcXVvdDthbXImcXVvdDsg Q2xhaW0gaXMgYmV5b25kIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzY29wZSBv ZiB0aGlzIHNwZWNpZmljYXRpb24uJm5ic3A7IFBhcnRpZXMgdXNpbmcgdGhpcyBjbGFpbSB3aWxs IG5lZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gYWdyZWUgdXBvbiB0aGUgbWVh bmluZ3Mgb2YgdGhlIHZhbHVlcyB1c2VkLCB3aGljaCBtYXkgYmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY29udGV4dC1zcGVjaWZpYy4mbmJzcDsgVGhlICZxdW90O2FtciZxdW90OyB2 YWx1ZSBpcyBhbiBhcnJheSBvZiBjYXNlIHNlbnNpdGl2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBzdHJpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48Yj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMzODc2MUQiPk9wZW5JRCBDb25uZWN0IGRvZXMgbm90IHNwZWNpZnkgYW55IHBhcnRp Y3VsYXI8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wcmU+DQo8cHJlPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjojMzg3NjFEIj4mbmJzcDsmbmJzcDsgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5j ZSB2YWx1ZXMgdG8gYmUgdXNlZCBpbiB0aGUgJnF1b3Q7YW1yJnF1b3Q7IGNsYWltLjwvc3Bhbj48 L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzODc2MUQi PiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgYSByZWdpc3RyeSBm b3IgdGhlc2UgdmFsdWVzIGFuZCBkZWZpbmVzIGEgc3RhcnRpbmcgbGlzdC48L3NwYW4+PC9iPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGgyIHN0eWxlPSJtc28tbGluZS1oZWlnaHQt YWx0OjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzM4NzYxRCI+My4mbmJzcDsgQXV0aGVudGljYXRpb24g TWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6IzM4NzYxRCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 ZGl2Pg0KPGgyIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaDI+DQo8L2Rpdj4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhlIGZvbGxvd2luZyBpcyBhIGxpc3Qg b2YgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSB2YWx1ZXM8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZGVm aW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb246PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVsIDE4LCAyMDE2IGF0 IDQ6MzAgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRz Y2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0KdGhpcyBpcyBhIExhc3QgQ2Fs bCBmb3IgY29tbWVudHMgb24gdGhlICZxdW90O0F1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVu Y2U8YnI+DQpWYWx1ZXMmcXVvdDsgc3BlY2lmaWNhdGlvbi48YnI+DQo8YnI+DQpUaGUgZG9jdW1l bnQgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlcy0wMSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDE8 L2E+PGJyPg0KPGJyPg0KUGxlYXNlIGhhdmUgeW91ciBjb21tZW50cyBpbiBubyBsYXRlciB0aGFu IEF1Z3VzdCAxc3QuPGJyPg0KPGJyPg0KQ2lhbzxicj4NCkhhbm5lcyAmYW1wOyBEZXJlazxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM2PR0301MB0637DCAAB49864F38B6CE60CF5E50DM2PR0301MB0637_-- From nobody Fri Sep 2 17:00:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A756312B039 for ; Fri, 2 Sep 2016 17:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgwp1xWNRiUk for ; Fri, 2 Sep 2016 17:00:42 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0127.outbound.protection.outlook.com [104.47.38.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFB212B005 for ; Fri, 2 Sep 2016 17:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fIzRfA364eqIDNGlgsC88wfaaqiVQxyUQ0W2kSPryp4=; b=bN3vZmdUlJp6vXVP9P3uvsY/9tzX1aZyVtvLfOrlblHb36JI4TSlPJQ29uY7/xsVjdw5GsFNJx0t/zebt5W79pW/+7r9BbDF+gXVZdfJVVtHaIihIQn608NQfDJH+pEXu0wvuwVOxtX0kboObEYzfdhzLw7SZdPhC7CI+QgAIR4= Received: from DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) by DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Sat, 3 Sep 2016 00:00:40 +0000 Received: from DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) by DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) with mapi id 15.01.0599.010; Sat, 3 Sep 2016 00:00:40 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-amr-values-01 Thread-Index: AQHR7Vu2r7DNSZRUJkG7mJ5S/pA+hKBnChHA Date: Sat, 3 Sep 2016 00:00:40 +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: [2001:4898:80e8:e::650] x-ms-office365-filtering-correlation-id: 8655c113-c79d-4c8e-ee35-08d3d38d57c5 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0637; 6:t0l8QyRbijrAlBDLQj3rD2UCqArPhh8qo/aPYjEZNKN5bysg57r/zY9mhTWhGcbkcSoXsYtILYSmVdQ0lfVRCNsGFOFd2tp0YOvyG52sRqjq/xf2nhrKxOekTpioK6EIvRWNOvm/EB/Xj1R+Nv89FgVi0RIki5vQF0awA7YBtBehV7LBKL/7TgDHrjyhR2eLJj0I3CTURupBCBpg6sRGVrh7iP/DSdpoL/ENcWorCUr5AzEsW4UOWjZ3x8BqT8lNM8vAaqnak03ycPnGqr6TYU77Gnm8oBteiy9bZP+w4ldmbQA4fgN6s7jlVdeDNQddyRmuCGoKup9AsImnN+U4mw==; 5:6lRt0zmurM7V2M8khsMGK3uYQkgfyKOA5I8ofG+n6NpXZRsgJJp58IHmoViRP1KSWbJj8l3owYP/GC0vT0Vkof7GNMq/SDfRrY3S0wruTffRKTLhDJBygTk7tAqzf/3L2EGRRPFQfYgFNRR0La4Wdw==; 24:Stqw5gF0KEViAtfDDsqLthGhiHttoYcZBpM4d+j/35Po8bxuZjcmVWvrk3rkVyPqhLXVXH8C1b7w3MPl0nlUPAruy5vuOH1pQ8+75xVH1BY=; 7:vldhRu7g8NSHa6G+VsWyryZck7eyZwYQteN4nfsHtqIrwaCGmtNLrshUg07j3nbojkY29nhLZ+E4xuLBgzutVYmpfeUHmnCcx3LhO3DJVy7fGDEqMs8Quxw7ZiFFCpeRvE0/FWciHIaa7qM3uG+TcJuNPTaRPIur1Ljg19yEE3OXgDXKdtyaG75gz6cB3hMXOjETSdDqdIMmhiKS/LsH3jkvNSpqTM58Ae8J1ps7KdEr20eCNhK10fwLkuG0CIUU x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0637; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17744754593026)(278428928389397)(43185275748208)(192374486261705)(194585677185034); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0637; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0637; x-forefront-prvs: 00540983E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(43784003)(13464003)(189002)(122556002)(2501003)(305945005)(6116002)(7736002)(7846002)(7696003)(230783001)(68736007)(54356999)(586003)(10090500001)(3660700001)(8936002)(86612001)(50986999)(76176999)(8676002)(74316002)(5002640100001)(3280700002)(86362001)(81166006)(33656002)(101416001)(102836003)(81156014)(189998001)(19580405001)(2950100001)(97736004)(92566002)(5660300001)(2900100001)(105586002)(107886002)(10290500002)(76576001)(11100500001)(99286002)(5001770100001)(9686002)(106356001)(5005710100001)(19580395003)(2906002)(10400500002)(77096005)(87936001)(8990500004)(15975445007)(551544002)(106116001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0637; H:DM2PR0301MB0637.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:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2016 00:00:40.3168 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0637 Archived-At: Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-amr-values-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 00:00:46 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgSGFubmVzLiAgUmVwbGllcyBhcmUgaW5saW5lLi4uDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMywgMjAxNiAxMjo1MSBBTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJq ZWN0OiBbT0FVVEgtV0ddIFJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDEN Cg0KSGkgTWlrZSwgUGhpbCwgVG9ueSwNCg0KSSBoYXZlIHJlYWQgdGhyb3VnaCBkcmFmdC1pZXRm LW9hdXRoLWFtci12YWx1ZXMtMDEuIE15IGVhcmxpZXIgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJl c3NlZC4NCg0KQXMgYSBzaGVwaGVyZCBJIG5ldmVydGhlbGVzcyBoYXZlIGEgZmV3IHF1ZXN0aW9u cy9yZW1hcmtzOg0KDQoxKSBUaGUgdGVybSAnbXVsdGlwbGUtY2hhbm5lbCBhdXRoZW50aWNhdGlv bicgaXMgdW5mYW1pbGlhciB0byBtZS4NCkNvdWxkIHlvdSBnaXZlIG1lIGFuIGV4YW1wbGUgb3Ig YSByZWZlcmVuY2UgdG8gYSBzcGVjaWZpY2F0aW9uPw0KDQpodHRwczovL3d3dy5sZGFwd2lraS5j b20vd2lraS9NdWx0aXBsZS1jaGFubmVsJTIwQXV0aGVudGljYXRpb24gaGFzIGEgY2xlYXIgZXhw bGFuYXRpb24uICBIb3dldmVyLCBJJ20gcmVsdWN0YW50IHRvIHJlZmVyZW5jZSBhIHdpa2kgcGFn ZSB0aGF0IG1heSBiZSB0cmFuc2llbnQgZnJvbSBhbiBSRkMuICBJZiBhbnlvbmUgb3V0IHRoZXJl IGhhcyBhIG1vcmUgc3RhYmxlIHJlZmVyZW5jZSB0byBzdWdnZXN0LCBwbGVhc2UgZG8gc28uICBJ bnN0ZWFkLCBJJ3ZlIGFkZGVkIHRoaXMgZXhhbXBsZSB0ZXh0IGZvciAtMDI6DQoNCgkgICAgRm9y IGluc3RhbmNlLCBhIG11bHRpcGxlLWNoYW5uZWwgYXV0aGVudGljYXRpb24gbWlnaHQgaW52b2x2 ZSBib3RoIGVudGVyaW5nIGluZm9ybWF0aW9uIGludG8NCgkgICAgYSB3b3Jrc3RhdGlvbidzIGJy b3dzZXIgYW5kIHByb3ZpZGluZyBpbmZvcm1hdGlvbiBvbiBhIHRlbGVwaG9uZSBjYWxsIHRvIGEg cHJlLXJlZ2lzdGVyZWQgbnVtYmVyLg0KDQoyKSBQSU46IFRoZSB1c2Ugb2YgUkZDIDIxMTkgbGFu Z3VhZ2UgYXBwZWFycyB0byBiZSBpbmFwcHJvcHJpYXRlLg0KDQpUaGFua3MsIHdpbGwgYmUgZml4 ZWQgaW4gLTAyLg0KDQozKSBDb3VsZCB5b3UgZXhwbGFpbiBtZSB3aGF0ICdyaXNrLWJhc2VkIGF1 dGhlbnRpY2F0aW9uJyBpcz8gV2hpbGUgeW91IHByb3ZpZGVkIGEgcmVmZXJlbmNlDQoNCmh0dHBz Oi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1Jpc2stYmFzZWRfYXV0aGVudGljYXRpb24gaGFzIGEg Y2xlYXIgZXhwbGFuYXRpb24uICBCcnVjZSBTY2huZWllciB3cml0ZXMgYWJvdXQgaXQgaW4gYSBi bG9nIHBvc3QgaGVyZSBodHRwczovL3d3dy5zY2huZWllci5jb20vYmxvZy9hcmNoaXZlcy8yMDEz LzExL3Jpc2stYmFzZWRfYXV0aC5odG1sLiAgRGVsb2l0dGUgaGFzIGEgcHJpbWVyIGF0IGh0dHA6 Ly9kZWxvaXR0ZS53c2ouY29tL2Npby8yMDEzLzEwLzMwL3Jpc2stYmFzZWQtYXV0aGVudGljYXRp b24tYS1wcmltZXIvLiAgVGhlcmUncyBsb3RzIG9mIG1hdGVyaWFsIG9uIHRoZSB3ZWIgYW5kIHRo ZSB0ZXJtIGlzIHByZXR0eSB3aWRlbHkga25vd24gaW4gYXV0aGVudGljYXRpb24vaWRlbnRpdHkg Y2lyY2xlcy4gIFVuZm9ydHVuYXRlbHksIGFzIHdpdGggIm1jYSIsIEkgZG9uJ3Qga25vdyBvZiBh IGdyZWF0IGF1dGhvcml0YXRpdmUgcmVmZXJlbmNlIHRvIGNpdGUuICBBbnkgc3VnZ2VzdGlvbnMg b3V0IHRoZXJlPw0KDQo0KSBDb3VsZCB3ZSBnZW5lcmFsaXplIHRoZSB0ZXJtICd3aWEnIHRvIG9w ZXJhdGluZyBzeXN0ZW1zIG90aGVyIHRoYW4gV2luZG93cyBhcyB3ZWxsPw0KDQpJIGRvbid0IHRo aW5rIHNvLiAgSXQgY29uc2lzdHMgb2YgYSBwYXJ0aWN1bGFyIHNldCBvZiBkb2N1bWVudGVkIHBy b3RvY29sIGludGVyYWN0aW9ucywgYXMgZGVzY3JpYmUgYXQgaHR0cDovL2Jsb2dzLm1zZG4uY29t L2IvYmVuamFtaW5wZXJraW5zL2FyY2hpdmUvMjAxMS8wOS8xNC9paXMtaW50ZWdyYXRlZC13aW5k b3dzLWF1dGhlbnRpY2F0aW9uLXdpdGgtbmVnb3RpYXRlLmFzcHguICBUaGF0IHNhaWQsIGJlY2F1 c2UgdGhlc2UgcHJvdG9jb2xzIGFyZSBwdWJsaWNseSBkb2N1bWVudGVkLCBvdGhlciBzeXN0ZW1z IChtYXliZSBTQU1CQT8pIG1heSBoYXZlIGFsc28gaW1wbGVtZW50ZWQgaXQuDQoNCjUpIEkgYW0g bm90IHN1cmUgd2hldGhlciBhbGwgbm9ybWF0aXZlIHJlZmVyZW5jZXMgaW5kZWVkIG5lZWQgdG8g YmUgZGVjbGFyZWQgYXMgc3VjaC4NCkZvciBleGFtcGxlLCAnb3RwJyBpcyBkZWZpbmVkIGluIGEg dmVyeSBnZW5lcmljIGZhc2hpb24gYnV0IHlvdSBsaXN0IEhUT1AsIGFuZCBUT1RQIGFzIG5vcm1h dGl2ZSByZWZlcmVuY2VzLg0KSSB3b3VsZCByYXRoZXIgc2VlIEhUT1AgYW5kIFRPVFAgYXMgYSBz dGFuZGFyZGl6ZWQgZXhhbXBsZXMgb2Ygb25lLXRpbWUtcGFzc3dvcmRzLiBJTUhPIHRoZSBzdG9y eSB3b3VsZCBiZSBkaWZmZXJlbnQgaWYgeW91IGluZGVlZCB3YW50IHRvIGRpZmZlcmVudGlhdGUg YmV0d2VlbiB0aGUgZGlmZmVyZW50IHRlY2huaWNhbCBtZWNoYW5pc21zIGl0c2VsZi4gVGhpcyBp cyBhIHJlYXNvbmFibGUgYXBwcm9hY2ggYXMgd2VsbCBpZiB0aGUgc2VjdXJpdHkgZGlmZmVyZW5j ZXMgYmV0d2VlbiB0aGUgbWVjaGFuaXNtcyBpcyBpbXBvcnRhbnQgZm9yIHRoZSBnaXZlbiBhcHBs aWNhdGlvbi4NCg0KSWYgdXNlIGNhc2VzIGFyaXNlIGluIHdoaWNoIGFwcGxpY2F0aW9ucyB3YW50 IHRvIGRlZmluZSBhZGRpdGlvbmFsICJhbXIiIHZhbHVlcyAiaG90cCIgYW5kL29yICJ0b3RwIiwg dGhleSBjYW4gdXNlIHRoZSByZWdpc3RyeSBlc3RhYmxpc2hlZCBieSB0aGlzIGFwcGxpY2F0aW9u IHRvIGRvIHNvLiAgSXQncyBleHBsaWNpdGx5IG5vdCBhIGdvYWwgb2YgdGhpcyBzcGVjaWZpY2F0 aW9uIHRvIGRlZmluZSBhbGwgcHJhY3RpY2FsIHZhbHVlcy4gIFJhdGhlciwgaXQgZGVmaW5lcyBh IGZldyB2YWx1ZXMgdGhhdCBhcmUgYWN0dWFsbHkgaW4gcHJvZHVjdGlvbiB1c2UgYW5kIGV2ZW4g bW9yZSBpbXBvcnRhbnRseSwgZXN0YWJsaXNoZXMgdGhlIHJlZ2lzdHJ5IGZvciBkZWZpbmluZyBt b3JlLCBhcyBuZWVkZWQgaW4gcHJhY3RpY2UuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCgkJCQlUaGFu a3MgYWdhaW4sDQoJCQkJLS0gTWlrZQ0KDQoNCg0K From nobody Mon Sep 5 12:20:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162C712B45C for ; Mon, 5 Sep 2016 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2YBogK1LfeE for ; Mon, 5 Sep 2016 12:20:49 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9422F12B455 for ; Mon, 5 Sep 2016 12:20:48 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e124so159305175ith.0 for ; Mon, 05 Sep 2016 12:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pgu3dSi5zoXlINsHXuOT3L9NrXYvWBpAohR09R4mCfo=; b=apXmkEnVkoT+cUG1tfmLKBuCGgJAZgBwLiPbxROt1lXdXmsMTchXiK0S7vFhLCiQcT QMDSms4UdGEG/eUsGp18n9BIU3LvZqfKb/py+ThDMeZmSVNtHRzR9zywgiOYrqdMkTu/ V5g0flw7F8lDAXoIeJ04sJLecfy0oJmUlFnOo= 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; bh=Pgu3dSi5zoXlINsHXuOT3L9NrXYvWBpAohR09R4mCfo=; b=DdcaQpr7O6Tm8qtX0/wEr69BV0S6y1M8atIH0GFxAiy9JZ/Ain7XdGAB50TB2jzzwv Lp9Y7pYI0qs53zNUCvaWEs3d5adYRj4BqGYl0N7q78khNHvA0JWLAMRTlLa3Idw8N7VZ 207wtfdPYzL15O0k3iIjYCuN1eJM6jxbJYnXs481/QdI8LfYr3Pad0M7zaFu9jv8cDdC GUiItOJyj4ecDXLv1p3n6zVyjkbCN8CT2C6fto61Q/pq9gwCbIL1l1fKSI8WP/cDgInV G69Jgw70rZ7hNue46fkzVZkxbG3VKJNTa0Zp+iZT1hLSKkQpa/ljjxJLZR5/KCdnewve 7Wbg== X-Gm-Message-State: AE9vXwOkKu3WpnIROHMv47Q1swLl82YN+q3t0TPlabjcHucnNvuwkAzb8ppRMUGX32NOCnREdCpyhkdpRxWqug== X-Received: by 10.36.189.68 with SMTP id x65mr23805677ite.97.1473103247995; Mon, 05 Sep 2016 12:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.23.88 with HTTP; Mon, 5 Sep 2016 12:20:47 -0700 (PDT) In-Reply-To: References: <57908256.7090107@gmx.net> From: Ulrich Herberg Date: Mon, 5 Sep 2016 12:20:47 -0700 Message-ID: To: Dick Hardt Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 19:20:51 -0000 Hannes, any updates on this? WGLC has ended almost a month ago. Regards Ulrich On Wed, Aug 3, 2016 at 8:53 AM, Dick Hardt wrote: > I reviewed the document and have no comments. > > +1 to adoption > > On Thu, Jul 21, 2016 at 1:05 AM, Hannes Tschofenig > wrote: >> >> Hi all, >> >> William has submitted an update, as promised during the OAuth WG session >> on Monday. Hence, we will start a Last Call for comments on the "OAuth >> 2.0 for Native Apps" specification. >> >> The document can be found here: >> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03 >> >> Please have your comments in no later than August 8th. >> >> Ciao >> Hannes & Derek >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Subscribe to the HARDTWARE mail list to learn about projects I am working > on! > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Wed Sep 7 06:04:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D372B12B4D1 for ; Wed, 7 Sep 2016 06:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.109 X-Spam-Level: X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0ygMYWvL134 for ; Wed, 7 Sep 2016 06:04:18 -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 11FD112B544 for ; Wed, 7 Sep 2016 06:04:17 -0700 (PDT) Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M81vR-1amtCx0QtN-00vcf8; Wed, 07 Sep 2016 15:04:14 +0200 To: Ulrich Herberg , Dick Hardt References: <57908256.7090107@gmx.net> From: Hannes Tschofenig Message-ID: <1f035924-7e4f-1ce6-f7f6-7aa29ac090bc@gmx.net> Date: Wed, 7 Sep 2016 15:04:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:el7HwNENYD52IOeiEEUZ+3Gt6bkupLAe3HqlqLhstWDqUi5MDN1 KgAIjXmwfw9pHHEEMr0JcVqJaef5Ujs8mzkRT77jSrXkZhwH8jT24wyy9Yzp/QjJsLJc7oo zYYBsyZZrtSO9eH6LJ4GY5gKgQHzCPLORa4lLJ7UyEHQP7T25IOWCU/4tGjjKohSgTrA2NA EkletKrldj/QxLzwyMeSg== X-UI-Out-Filterresults: notjunk:1;V01:K0:L7Z5ZoE04cw=:d2PczgG7nQi63pRO6c5PJ+ N8ehR8OCU1R2unmIm06glxrt+6B2B/uYRxwcVquyl0rCfYMDnRomG1gemnlfGkw671KaGn7MI 77rqOUJNKGck3WnwN+3Ya4RMVAK0FGHGP94waI9m+uY9WR1Ax/lS/VDpLcas8pzTfCz5ppijT I2hBcjNLjV0tJlhk46SsIDM/BL34BZPqqlXSS2pn+Qrx5K9V+bXvygqzzV87h2u+3l0VgrAkE xhvPgrDnIX5ZrDI+WcBRhVYhTkq6bDftjyho083AbnY2StpinHN+ndSljFybjTDzS6u79A+98 id4JkjOmzvMzq6WM2ZGO4Z2AjnzfhTqPIsraHFmUYIPIzXK0ztKPsi3q1UcRobsLxJUZs4k+4 cwQgaHf07zS6Lb7hFqR+QwGbHxkpu6l/q+VFJ8IkM1Bxe9MV0XXusXbWshzu+b9aFfJRL6uFS t/cfs11fZP+NsjMreWty6Gycw0+oV0RrH4pSMn+YMfpH9qN/lAXMs3V3rUbN1g4thhNcXjQJj Ax18GDuLeE46zglzpav3indMbceAhlBiJjTBAfoeaKfTnjj0jIltXbVsJmQaFmu0XcLoMHtHc Ji7qVsU3ikwW2+RGznABkpGdC5Vyuyj+kYZTsN26+Cna0dgbjNkSGBLdTsjWie9tXgAD+Pzl5 1RaQYv7LTYA+YZgFm2ZVDESecs7DpOQkzlyNZe4RqrF0qyqj243DXsuF7hWVKIpsN11LEX2Q0 jcRkG/zNZu57W6EYSx5cYnctEJfoXnrgRSt+FeN4Mfn5+W3boYjxsTzyOLe20p8mzeeBNk/Rl +1Tz52B Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 13:04:22 -0000 Hi Ulrich, I will be working with William on the shepherd write-up. Ciao Hannes On 09/05/2016 09:20 PM, Ulrich Herberg wrote: > Hannes, > > any updates on this? WGLC has ended almost a month ago. > > Regards > Ulrich > > On Wed, Aug 3, 2016 at 8:53 AM, Dick Hardt wrote: >> I reviewed the document and have no comments. >> >> +1 to adoption >> >> On Thu, Jul 21, 2016 at 1:05 AM, Hannes Tschofenig >> wrote: >>> >>> Hi all, >>> >>> William has submitted an update, as promised during the OAuth WG session >>> on Monday. Hence, we will start a Last Call for comments on the "OAuth >>> 2.0 for Native Apps" specification. >>> >>> The document can be found here: >>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03 >>> >>> Please have your comments in no later than August 8th. >>> >>> Ciao >>> Hannes & Derek >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> >> -- >> Subscribe to the HARDTWARE mail list to learn about projects I am working >> on! >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From nobody Wed Sep 7 08:15:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B846912B1DE for ; Wed, 7 Sep 2016 08:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.109 X-Spam-Level: X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RM4D6Kx_u2a for ; Wed, 7 Sep 2016 08:15:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F6F12B12D for ; Wed, 7 Sep 2016 08:15:17 -0700 (PDT) Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M8ZtH-1anVFR3IJ9-00wATY for ; Wed, 07 Sep 2016 17:15:14 +0200 To: "oauth@ietf.org" References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> From: Hannes Tschofenig Message-ID: <0ad395b4-a2ab-5c62-0150-73ccd7810603@gmx.net> Date: Wed, 7 Sep 2016 17:15:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gSRT3YfkvKuvtYh6V5ArtoaH0pHgDyWZ4ryUm9R3mUekirgraPs bP0qFb1YIXuDzfAnc41/1h8o0+eMZcAAHMIHy68f6eo5HaVKH21nj2Zg/DXJom3UGkDT3Is ELMNzxSGxl6ifCNT7caIO6JTLfH2iuKU+l1MbMBeWGy0XbK89MlyrdG3wx2SKEmXT0qTNd5 Ri3SeI9lD/JJPhyXtL5rw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ujdxwdXmigE=:T4nWNIYedlE8qQi8tBDX8n MCFqXwl6RmDf6Du47vzbdt3CJaDf73X49hhiWJ/2LThBDlH65xNsJ3wg/CF6IZKmr6iWfpH0I 0UpR7h87+DyVityYXSXVPdQh+3Ba1SXFjg/Kn6uWPCg8Ph6nR66sqBGsUMvNmAPFkhuzOp50U AUvAmuJsbjrit/f1hrUg8gh0Y3pKRoCPEwdfGSEJdLj8x3T11t+3+A5qJQNgjwmSOSd036tXV gymIn21BH6LErAIoXAfs+Ytxipar22egtFhzmsKIo9CPZ6wEJHNqN4MiWf2M8ii5anpCzY4pI A3ZadD0BJzvzoQxDKHNs24OtacJr4ojLsp7/rfX8A/Dw4Hr1MoRZOZ3JIEMns/CtaoYJSOU5R FaUHVEyAT7G4uD4kQGNDeZjle9co793ZxpfUklH2ETVtLmJSPwqtAvlfHfv26POmvESPT20bS KKfcrUeXYoNsMNoRrr6eizo3rxXyePbV0VMZieW1WxE6kloxmPebcU3q3yBV+BzYVkONDbSZ2 aLxymEpfcCQvgk2TBPOu6ZdEiCAjGDaTt1PmIBZ5a8LuAh6v4H5mGlwFD14m5DlhN/htiifnY J3AEEBQcjpo2qKbgieimDWCir8OagRn1RzmyX0x0+nPEpslg3TrKbZe0H7tzUFQwPF7I4qwj2 cKrFKIItcj3lXc/oMuyMlrt8wl7j7yK6UIaNTmEhzvYUgUCT5f6PpYEqcOnVsUOVCWikzfDBk yxp0ZnVDNyTgZHvua+b1hWuGM6K1e06m0/rLYHaNMrZOJ4SyJJuI5I3RrxEvXcT/3pjtQmX0F WeTxbwU Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 15:15:20 -0000 The call for the token binding draft has been concluded and I asked the authors to submit a -00 WG document version. Ciao Hannes On 08/03/2016 09:45 AM, Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of the 'OAuth 2.0 Token Binding' document > bundle* following the positive call for adoption at the recent IETF > meeting in Berlin. > > Here are the links to the documents presented at the last IETF meeting: > https://tools.ietf.org/html/draft-jones-oauth-token-binding-00 > https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 > > Please let us know by August 17th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Derek > > *: We will find out what the best document structure is later, i.e., > whether the content should be included in one, two or multiple documents. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Wed Sep 7 19:39:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A9A12B280 for ; Wed, 7 Sep 2016 19:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpt1wu3QHtgh for ; Wed, 7 Sep 2016 19:39:05 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A58212B0A7 for ; Wed, 7 Sep 2016 19:39:04 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id i184so233001589itf.1 for ; Wed, 07 Sep 2016 19:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kj97bbDDOVeBabY9JwGgCY+RHiFDrXxHcSsxxts/BpQ=; b=iSPoaaBhEskhLOR9ZWZq+MtQMm8h0gpoR2hKZkrSfoCSpG20d8MUgefFuDtvkHF3OZ V8piZLdPkdPf7ItAWTJo1OdMgaUMuwiMhuPlfpl6VFncrDucYF/FxkF0ifrFHTd0PPpn /8/W/+R5A6bzqN5a/GwkGyGpFqcHQxIkAVivw= 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; bh=Kj97bbDDOVeBabY9JwGgCY+RHiFDrXxHcSsxxts/BpQ=; b=H9LJsiTZcYRdbvIGrME7HfytK7TYz4488+cAsfrPu3F74nEd6vKm1yq7iBqEPHmnge zem2WR7CNysW1k4fQt2Ag5FxNMxhXlkvIdg8Iwnq8eEpmtRunfAEPYMFhxb7beFVPjCa XWO61PL+A4dFXxxCKMPv5e7qmVFW5TZtWmX4gV/lwF2ZJAyGyS+/7KAFchkl6vBwybLg vZfCYShkCJsKxCpH/NaBIG7lJCT3Vzh6q526cnZEnbauCehtew4K04F5nMtcB8XuI8vS PouwSqZkgm8dcxNJZJWQIoCXmaZQH7Eedd5eJ8OvvuHQTXd772hhrZ81AIlg9rGLqVCF obPg== X-Gm-Message-State: AE9vXwNRbSlSKqubyAVGy4F8UGQPslzLemuVwc4lebuajQthZ/XRJ88mzCahCc5PYK45j+tA9qt7xF2gxSYChQ== X-Received: by 10.36.40.144 with SMTP id h138mr12521889ith.31.1473302343904; Wed, 07 Sep 2016 19:39:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.23.88 with HTTP; Wed, 7 Sep 2016 19:39:03 -0700 (PDT) In-Reply-To: <1f035924-7e4f-1ce6-f7f6-7aa29ac090bc@gmx.net> References: <57908256.7090107@gmx.net> <1f035924-7e4f-1ce6-f7f6-7aa29ac090bc@gmx.net> From: Ulrich Herberg Date: Wed, 7 Sep 2016 19:39:03 -0700 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 02:39:07 -0000 Thanks! On Wed, Sep 7, 2016 at 6:04 AM, Hannes Tschofenig wrote: > Hi Ulrich, > > I will be working with William on the shepherd write-up. > > Ciao > Hannes > > > On 09/05/2016 09:20 PM, Ulrich Herberg wrote: >> >> Hannes, >> >> any updates on this? WGLC has ended almost a month ago. >> >> Regards >> Ulrich >> >> On Wed, Aug 3, 2016 at 8:53 AM, Dick Hardt wrote: >>> >>> I reviewed the document and have no comments. >>> >>> +1 to adoption >>> >>> On Thu, Jul 21, 2016 at 1:05 AM, Hannes Tschofenig >>> wrote: >>>> >>>> >>>> Hi all, >>>> >>>> William has submitted an update, as promised during the OAuth WG session >>>> on Monday. Hence, we will start a Last Call for comments on the "OAuth >>>> 2.0 for Native Apps" specification. >>>> >>>> The document can be found here: >>>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03 >>>> >>>> Please have your comments in no later than August 8th. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE mail list to learn about projects I am working >>> on! >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> > From nobody Thu Sep 8 01:11:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA56212B0A2 for ; Thu, 8 Sep 2016 01:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru01xedHhsQr for ; Thu, 8 Sep 2016 01:10:59 -0700 (PDT) Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (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 6C18B12B08C for ; Thu, 8 Sep 2016 01:10:59 -0700 (PDT) Received: from [192.168.1.3] ([95.43.60.86]) by :SMTPAUTH: with SMTP id huPhbqrpf8KrfhuPjbneQd; Thu, 08 Sep 2016 01:10:28 -0700 To: Mike Jones , "oauth@ietf.org" References: <578CE7F4.4080600@gmx.net> <8b9dd6a2-d7fa-fe92-f6d4-83044c574167@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <27988343-2d2d-4a17-a875-9c4cb1197dc8@connect2id.com> Date: Thu, 8 Sep 2016 10:10:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000902080602090702020101" X-CMAE-Envelope: MS4wfAbC1VcxjMzw7rsQb7MGuU7kzJNWQ10wWrCWg7+MLrBiS2TB0jmvB5X//LZxEZe19GwyvPg33CGmZH6VLHT5ksoxxF8sROCKnh3paJYwOQaBRNdkxSfg oBw/hP+Uo3UhC5TODqEmHxDnBjp+gPXLWZqcLSpWL1OR2AgF2AF2gbwSOMeYa9ij4jKtKRo+RgBdZMWi1Gv6lINyzUwNR/Ape0g= Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 08:11:01 -0000 This is a cryptographically signed message in MIME format. --------------ms000902080602090702020101 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Mike, "hwk" and "swk" would do. The actual auth method is indeed proving key possession, whereas x.509 is mostly about formatting. Vladimir On 03/09/16 01:20, Mike Jones wrote: > Thanks for your question, Vladimir. No, there is not currently an X.50= 9-specific value defined. However, there are these related values: > > hwk > Proof-of-possession (PoP) of a hardware-secured key. See > Appendix C of [RFC4211] for a discussion on PoP. > > swk > Proof-of-possession (PoP) of a software-secured key. See > Appendix C of [RFC4211] for a discussion on PoP. > > Given that x.509 authentication is PoP authentication, these might appl= y, depending upon your use case. Are you using an X.509 "amr" value in p= ractice? Remember that even if such a value isn't already in use now, if= it is ever need in the future, it can always be added later via the regi= stry established by this specification. > > Thanks again, > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir Dzhuv= inov > Sent: Wednesday, July 27, 2016 8:14 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Meth= od Reference Values" > > > > On 18/07/16 17:30, Hannes Tschofenig wrote: >> Hi all, >> >> this is a Last Call for comments on the "Authentication Method=20 >> Reference Values" specification. >> >> The document can be found here: >> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-01 >> >> Please have your comments in no later than August 1st. > Thanks Hannes. > > Do we have an "amr" value for x.509 certificate based authentication? > >> Ciao >> Hannes & Derek >> > -- > Vladimir Dzhuvinov > > --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------ms000902080602090702020101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7 r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+ 4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ 4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA5MDgwODEwMjVaMC8GCSqGSIb3DQEJBDEiBCDt3blayXB6QeoXwDsDctOQTWn5Q6nK lWHFVtjDUsf9BTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQCgGQQDkoZ/ hjibkDUdlWKN7/FssIWBqzriTfLHn+BDLL8AV7yLJagVeChl4vdIDPHdWSejUWNw3zhKttiQ hsNYYUD9KN9F6UTjUxPS6+ijhNXwVis1uITC1hfADE64+nZLPzvCY9fSCu0+ShjNBImBCJ7E OOkiYNAVGpmGFkAsZ4VaSHAudJbt9HlSkVj8qL2+c/bSnZt/ZiLJg+2/LXf7rcWXWfTBVXS+ FM0+hyqME3xn3IQ7nfyHbcP1w4xhVro1ISlYN3hXy/DrF2CBnFAGRvNBZR+0YehWRMKWY2X3 KFC8tjK0VWDkPVl2n9pAVxG9JN81bcjfUVYwwfx7pbiiAAAAAAAA --------------ms000902080602090702020101-- From nobody Thu Sep 8 03:50:07 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF7312B0AF; Thu, 8 Sep 2016 03:50:02 -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.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147333180211.30770.9962171106983810181.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2016 03:50:02 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 10:50:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones John Bradley Brian Campbell Filename : draft-ietf-oauth-token-binding-00.txt Pages : 11 Date : 2016-09-07 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens and Refresh Tokens. This cryptographically binds these tokens to the TLS connections over which they are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-token-binding-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 8 06:23:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2804F12B485 for ; Thu, 8 Sep 2016 06:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv5jfvnv0mxR for ; Thu, 8 Sep 2016 06:23:30 -0700 (PDT) Received: from mx0b-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (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 1A80312B61E for ; Thu, 8 Sep 2016 06:02:43 -0700 (PDT) Received: from pps.filterd (m0074408.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u88Cqo8M006651 for ; Thu, 8 Sep 2016 08:02:43 -0500 Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) by mx0a-0019e102.pphosted.com with ESMTP id 25b66frf0c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 08 Sep 2016 08:02:43 -0500 Received: by mail-qt0-f200.google.com with SMTP id v24so93048995qtv.2 for ; Thu, 08 Sep 2016 06:02:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WOhBswtDUJHix4aedE8NuqmYtIywx1Ku5qs4Tqjwu1o=; b=ZRu3AhJLLGDh19mwoJtsLuKP2DzCwJiA60YFvlrysPJmzK50ZYtqwWtKmksVHXDUVI djJszf01rUH0rOmMY4+hJwiitYiOyr8T/JPurK9fYuE8AaXyXB4NY16cvRYUP85vZkbW ZcRPc4JpR/xKy3WAT0XL2kw65IQlEv1RdpqC49El/E8xWvMlna6CA2uhjjb1DfXDZvFh /vqdwDiQdIe7XldBQBJRa5t4aL5LSj9KUlIT84bAKmLfjLH9jkZOXVuqIgmoXzSLEpBX LDzTJCCnuK54ml45K0951pKdI0T5ekMuVyH6u6/bBvqyqEpDObDyyIMQkaEskP0nnq3l 9omw== X-Gm-Message-State: AE9vXwPhPvGjznEAeNRsb5bgVB0R11/PXdfIa4IfhA0caPGh7dvFXw4OKGTxfLu3eIDmaTQsP3uFf3H1lGQB8uuGZrOSIgZTiEXUCV4d6iWsL+z5y7Omkf3Cm6OnoVBnbxBnEm4/H2MgfDER X-Received: by 10.129.39.205 with SMTP id n196mr23511657ywn.294.1473339762235; Thu, 08 Sep 2016 06:02:42 -0700 (PDT) X-Received: by 10.129.39.205 with SMTP id n196mr23511640ywn.294.1473339762097; Thu, 08 Sep 2016 06:02:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.162.40 with HTTP; Thu, 8 Sep 2016 06:02:21 -0700 (PDT) From: Adam Lewis Date: Thu, 8 Sep 2016 08:02:21 -0500 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=001a114092a22778c8053bfea56a X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=2 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609080189 Archived-At: Subject: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 13:23:33 -0000 --001a114092a22778c8053bfea56a Content-Type: text/plain; charset=UTF-8 Hi, The WG is currently putting together best practices for native apps. I would like to better understand the best practices around ua-based-apps, especially as it relates to token storage. I've read various blog posts about the preference between storing tokens in cookies vs. Web Storage (localStorage/sessionStorage). The current set of specs are rather silent on the matter, as it is more of an implementation issue (but that is where most mistakes are made). What is the WG's guidance on this? --001a114092a22778c8053bfea56a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The WG is currently putting together best practices for native app= s.=C2=A0 I would like to better understand the best practices around ua-bas= ed-apps, especially as it relates to token=C2=A0storage.=C2=A0 I've rea= d various blog posts about the preference between storing tokens in cookies= vs.=C2=A0=C2=A0Web Storage (localStorage/sessionStorage).=C2=A0 The curren= t set of specs are rather silent on the matter, as it is more of an impleme= ntation issue (but that is where most mistakes are made).
=
What is the WG's guidance on this?
--001a114092a22778c8053bfea56a-- From nobody Thu Sep 8 09:26:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B27E12B115 for ; Thu, 8 Sep 2016 09:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7XINC7P5sGp for ; Thu, 8 Sep 2016 09:26:26 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0105.outbound.protection.outlook.com [104.47.38.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A566612B0E2 for ; Thu, 8 Sep 2016 09:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jLeX/an5FGmB8um9tJj0lfnhD01JKPOJM6CgdJUc0UM=; b=hTO2iACD0IimIG81SJx5bPrBYc764H1HKKqNBq+bkPB7vMBLtBstvUClXoJr/oSOiiOEUaV0w3KK033ireNPeE/AO1bEkyM4PFrn3ZbqMd+/GAetfeUVrjpnjJ8UTmtnR5WyoFQyARfORoep81VdCO9hk2C6B7jb28HRZSyavc4= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Thu, 8 Sep 2016 16:26:24 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0599.016; Thu, 8 Sep 2016 16:26:24 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Initial Working Group Draft of OAuth Token Binding Specification Thread-Index: AdIJS9JttjQ4CaHHRLSVluLCqTr6tA== Date: Thu, 8 Sep 2016 16:26:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.91.120] x-ms-office365-filtering-correlation-id: 85bab331-2d43-468d-846f-08d3d804e03b x-microsoft-exchange-diagnostics: 1; BN3PR03MB2355; 6:3C2wHpxvLJa/aMscuK3HpifkVt11u/vZc8FzHzKTtvpQWad9yjfRH0GLZUXr0XTnIHMyVVcSGqB82BDZrlENt6drukWtemyToWkt7JppYn3JvE1Dj2k7uCsYLudfXaqQXdaly/t5YdcXsi3a54DlesrOyCoop8FaO8v7RByrbkoCQvcOHvqkayio/CBovZxQriwME4jIXRZPFoNhiLnDjXetLSYoyaHHuPJgoPtnno44fml4JqkNEaDvW1bpBKIIa0rxPRos2aBZ2q6M2QT3RLBKZFSYBkomKmzQkoLPWoDvCMZiwlEj2K3D3sDAfjd8xBX59t56tJ7Wf7vcCGHkOQ==; 5:MFIhXt938JJR0dWNjYDFU43kXf44psXHt2EiQ3L2M7jVNbL8ID8wdLHxvNKGNOfHoqjKRDGF2f9lllFrGr+mJ+N2J7xvnNQKkZX6A8tg3qmhoGPE2EJNpLrZsfDLqwbMWm+/zh6B8VsJhjBZvI0P5Q==; 24:PV6LYSO3CX5Zd2mLL+PlQuroMNKWewPWqKIAS3yvqwt8WOJ3HEZ9fxOTxktUaKW8Qb7R19FMZiyroA1VAlkMXMTG6PJCNx6n3wm8eLnG3KA=; 7:wvN2s7zqQEO7+fd4bYhLxJcPjzGG1N3aPtku7+u7S1Im56lxbzMuvsqeOdMHqviy96ReS7BFg8ucBsqU8GMcR6eXSYHL0qYw6qsw1CLNWr790EuPmaw5qj1QN1eXYo1Xgdck22v+3OSiiRra1WBiN32Sr1YtVkxys90vhs9b/0JuHf+ftnORiTLh1x4xZuFUaiBZrRX9qpfUU8BW4Z2WvDDK+bjC10metCvYDgDLDntakPcCYU4FLRC6ZKZahDiK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2355; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB2355; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2355; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(189002)(3846002)(11100500001)(3280700002)(2351001)(87936001)(8676002)(5630700001)(19625215002)(7906003)(10400500002)(5005710100001)(790700001)(7846002)(50986999)(7736002)(7696003)(101416001)(2501003)(10290500002)(97736004)(110136002)(77096005)(107886002)(76576001)(10090500001)(15975445007)(19580395003)(74316002)(450100001)(2900100001)(8936002)(2906002)(102836003)(122556002)(33656002)(5002640100001)(19300405004)(16236675004)(3660700001)(86612001)(81156014)(586003)(92566002)(68736007)(5660300001)(81166006)(99286002)(229853001)(66066001)(6116002)(189998001)(86362001)(19617315012)(5640700001)(8990500004)(54356999)(9686002)(106356001)(105586002)(1730700003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2355; H:BN3PR03MB2355.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB23556474E2DC2AD4F18144FEF5FB0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2016 16:26:24.0962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2355 Archived-At: Subject: [OAUTH-WG] Initial Working Group Draft of OAuth Token Binding Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 16:26:28 -0000 --_000_BN3PR03MB23556474E2DC2AD4F18144FEF5FB0BN3PR03MB2355namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The initial working group draft of the OAuth Token Binding specification ha= s been published. It has the same content as draft-jones-oauth-token-bindi= ng-00, but with updated references. This specification defines how to perf= orm token binding for OAuth access tokens and refresh tokens. Note that th= e access token mechanism is expected to change shortly to use the Referred = Token Binding, per working group discussions at IETF 96 in Berlin. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-token-binding-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-token-binding-00.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1605 and = as @selfissued. --_000_BN3PR03MB23556474E2DC2AD4F18144FEF5FB0BN3PR03MB2355namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The initial working group draft of the OAuth Token B= inding specification has been published.  It has the same content as d= raft-jones-oauth-token-binding-00, but with updated references.  This = specification defines how to perform token binding for OAuth access tokens and refresh tokens.  Note that the access tok= en mechanism is expected to change shortly to use the Referred Token Bindin= g, per working group discussions at IETF 96 in Berlin.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oauth-to= ken-binding-00

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft-ietf= -oauth-token-binding-00.html

 

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

 

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

--_000_BN3PR03MB23556474E2DC2AD4F18144FEF5FB0BN3PR03MB2355namp_-- From nobody Thu Sep 8 10:46:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64EB12B21F for ; Thu, 8 Sep 2016 10:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FPGnIqLQETA for ; Thu, 8 Sep 2016 10:45:58 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F9312B2D1 for ; Thu, 8 Sep 2016 10:45:58 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id p64so20412791pfb.1 for ; Thu, 08 Sep 2016 10:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ST278pPmCHs74epXvLEhF7Fz8PsKeY2URmFKdu9tCK0=; b=JIC0iFSOqUBovXJIPbnejhEGW8onb3A4Vn+Ydk7Ja/U55ho8vMJwKV++g4uW6n1LVC CEGcp25R2IUd6CZjTIbxfvWx8czC5DwYIClFCPWWU0KqTuDAGT1Gd2TpBA/pqljK4lW4 2Hnev15jeEuV953CdyynUZ98np1qajO6oAKi4mVOL1y82kz5yznDDBNt/w1SMu9ByKIx shnbTZNoQT5iQR8kWGAFdK4em+4xCZ4KApHtXgOkIJnDO+MmxvaQtUhqNVYgagKKJX9g 7ItqdmnIlmD3/hxwfQRdK5EuFukecRlw/BJ9EaQg913HmQWit8jD/S9TQxDXjrjcYcRv 9txQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ST278pPmCHs74epXvLEhF7Fz8PsKeY2URmFKdu9tCK0=; b=V36EzpFHjfc0A0XapdMi9u6mefdcDm2GJFnfWIC1CZ5RMXWkKdqK42JjEPZ+CIawdO MSeslghqsVde2QwbrafFGZSrenHGeowaWZiti0f93RtzUnt8IErehfr/DyXrU8R2NO+C 0cfztJe4TcvrbKer2T5mKv5wgUrsy9sMdE5ZKNvK7a0fGdPH7XilqZTmoG90SC7sJ54n 7ANn6w1U5MKgNEzYCTgJIvZwQkDjQGMfpuwRsD6TeCwNfNqV+QB21WWdYzAj01hiAto5 wz30XgFg4FXr3iunPA5YAjVPRY2GrtKBvZh8eLodmC8Bm/b2IG37rfNsva9VN1RLdNWG MzOg== X-Gm-Message-State: AE9vXwMyEkTwqvUGneUCn4R8JqLXJHaZ6ewLPCQ7am+igMw0b/SVlZcuZrps3JlbIh9ubRTc X-Received: by 10.98.219.198 with SMTP id f189mr1469061pfg.100.1473356756580; Thu, 08 Sep 2016 10:45:56 -0700 (PDT) Received: from ?IPv6:2605:e000:112b:c167:4463:4989:40ce:9b10? ([2605:e000:112b:c167:4463:4989:40ce:9b10]) by smtp.gmail.com with ESMTPSA id d5sm57798349pfc.4.2016.09.08.10.45.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Sep 2016 10:45:56 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-16AA2BDA-F134-4566-8DFE-F15C6F371C52 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Thu, 8 Sep 2016 07:45:54 -1000 Content-Transfer-Encoding: 7bit Message-Id: References: To: Adam Lewis Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 17:46:00 -0000 --Apple-Mail-16AA2BDA-F134-4566-8DFE-F15C6F371C52 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the web world, cookies for session identifiers are much safer - since we c= an use HTTPOnly cookies to protect them from theft via XSS. The same mechani= sm is not possible for localStorage. Overall, security folk say =E2=80=A2kee= p sensitive data out of localStorage=E2=80=A2 since one XSS and it's stolen.= There is also a huge body of work underway to make secure cookies even more= so. I'm not sure how this translates to native apps. -- Jim Manico @Manicode > On Sep 8, 2016, at 3:02 AM, Adam Lewis w= rote: >=20 > Hi, >=20 > The WG is currently putting together best practices for native apps. I wo= uld like to better understand the best practices around ua-based-apps, espec= ially as it relates to token storage. I've read various blog posts about th= e preference between storing tokens in cookies vs. Web Storage (localStorag= e/sessionStorage). The current set of specs are rather silent on the matter= , as it is more of an implementation issue (but that is where most mistakes a= re made). >=20 > What is the WG's guidance on this? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-16AA2BDA-F134-4566-8DFE-F15C6F371C52 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In the web world, cookies for session i= dentifiers are much safer - since we can use HTTPOnly cookies to protect the= m from theft via XSS. The same mechanism is not possible for localStorage. O= verall, security folk say =E2=80=A2keep sensitive data out of localStorage=E2= =80=A2 since one XSS and it's stolen. There is also a huge body of work unde= rway to make secure cookies even more so.

I'm not sure how this translates t= o native apps.

--
Jim Manico
@Manicode
=

On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.lewis@motorolasolutions.com> w= rote:

Hi,
<= br>
The WG is currentl= y putting together best practices for native apps.  I would like to bet= ter understand the best practices around ua-based-apps, especially as it rel= ates to token storage.  I've read various blog posts about the pre= ference between storing tokens in cookies vs.  Web Storage (localS= torage/sessionStorage).  The current set of specs are rather silent on t= he matter, as it is more of an implementation issue (but that is where most m= istakes are made).

What i= s the WG's guidance on this?
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-16AA2BDA-F134-4566-8DFE-F15C6F371C52-- From nobody Thu Sep 8 11:15:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6712B20C for ; Thu, 8 Sep 2016 11:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.227 X-Spam-Level: X-Spam-Status: No, score=-4.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxq6XcLB2I19 for ; Thu, 8 Sep 2016 11:15:16 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (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 1B6A312B206 for ; Thu, 8 Sep 2016 11:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1473358515; bh=D1VgaUeScxDF5e4x2nQTzL++uq3gV04x8q/NqABne0k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=e9eY/1W8pfHuDSr25hIfRyf1GiPGtba9f7eFeUodT3tI1zV9qW6CFZCPuq7+eR6wZLL1PfMIU7Z6T9TyoBrrYUqQLBwWLO7hqipVqYGybWcoJKWMbESM683f3yTjLNYT15a0RgmuBVHr4hvUODPs08vEU+I/eLPTwvI+T1ndQ0rm42L/r95AHZoxSXDFFRIk/hgaR9dT07q04cs+u+s0DzGF1wE4R/B0fP5BQ1GxSj9JU2HCbkiPjk9w3jlW2aFxSV0afIgMtErDNFv2XvIkXj+iInA8mF+jYsR6nM6MlIFn3vbyYe+xXstgd4HL2Gxjha79nFIwJ1MDo8flWRREtw== Received: from [98.139.170.180] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 08 Sep 2016 18:15:15 -0000 Received: from [98.139.212.242] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 08 Sep 2016 18:15:15 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 08 Sep 2016 18:15:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 255179.63159.bm@omp1051.mail.bf1.yahoo.com X-YMail-OSG: i2ftQmMVM1lstY8Z9WN35kifrFMTl7NXkRsc9tvGwRDegw1oCcpATqeIQvL4ABE kmgtKPKacIEstit58LWh3ydDzGo2m0CRUvx.vdZ2GvxAhF.CLOqVLil6Xir2IGEhc0dAEKQL1uHV Ldc_4V93Df3xNAvqk3kabD71zsnR2GiWmN_l1NH8dcxYURoKA876PRUuddidXltJG9Eq78xbSi9w iRP5Hj92AwMZCur2wFaoOsrM.PCWRhctW8jz4P8oCQA3Vys4SAZD5pARYWmFT2ML72_rHZo31uBP _1ttDoLMhSy2qajtPxWVHazB.aBqqo9Os2UrEyIE4TahJkuyGD.WH2LHRH_HrXL7.yJmsxXlvB0W 1ZAPaMjzaA6mijifIL3krOK60DPP20oYVlrkhi_F_gdV02W3zyrmprPVQ4gcv_szVvSXj.cc5v5E qW5ilaZ.5hWJCGlGTLmlxJHJT3y6kSvFS3SkMJnw2pnGPuRdYf1JQ0XnhOmg4PtizhAca_kw.RS6 t4z3yUXY1lyRhLv7ZRX0PCL9VU9u9l9xZYhPc Received: from jws10643.mail.bf1.yahoo.com by sendmailws169.mail.bf1.yahoo.com; Thu, 08 Sep 2016 18:15:14 +0000; 1473358514.750 Date: Thu, 8 Sep 2016 18:15:00 +0000 (UTC) From: Oleg Gryb To: Jim Manico , Adam Lewis Message-ID: <632483756.1929562.1473358500330@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1929561_2037331673.1473358500294" Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 18:15:18 -0000 ------=_Part_1929561_2037331673.1473358500294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, It's outdated a bit. Since SPA is a new normal now, it becomes extremely di= fficult to enforce HTTPOnly flag, because JS needs access to secrets includ= ing those stored in cookies. 5-10 years ago I would always enforce HTTPOnly= and now - I can't. Thanks,Oleg.=20 From: Jim Manico To: Adam Lewis =20 Cc: OAuth WG Sent: Thursday, September 8, 2016 10:45 AM Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage =20 In the web world, cookies for session identifiers are much safer - since we= can use HTTPOnly cookies to protect them from theft via XSS. The same mech= anism is not possible for localStorage. Overall, security folk say =E2=80= =A2keep sensitive data out of localStorage=E2=80=A2 since one XSS and it's = stolen. There is also a huge body of work underway to make secure cookies e= ven more so. I'm not sure how this translates to native apps. --Jim Manico@Manicode On Sep 8, 2016, at 3:02 AM, Adam Lewis w= rote: Hi, The WG is currently putting together best practices for native apps.=C2=A0 = I would like to better understand the best practices around ua-based-apps, = especially as it relates to token=C2=A0storage.=C2=A0 I've read various blo= g posts about the preference between storing tokens in cookies vs.=C2=A0=C2= =A0Web Storage (localStorage/sessionStorage).=C2=A0 The current set of spec= s are rather silent on the matter, as it is more of an implementation issue= (but that is where most mistakes are made). What is the WG's guidance on this? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 ------=_Part_1929561_2037331673.1473358500294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jim,

It's outdated a bit. Since SPA is a new normal now, it= becomes extremely difficult to enforce HTTPOnly flag, because JS needs acc= ess to secrets including those stored in cookies. 5-10 years ago I would al= ways enforce HTTPOnly and now - I can't.

Thanks,
Oleg.
=
From: Jim Manico <j= im@manicode.com>
To: Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
= Sent: Thursday, September 8, = 2016 10:45 AM
Subject:= Re: [OAUTH-WG] best practices for implicit grant / token storage

In the web w= orld, cookies for session identifiers are much safer - since we can use HTT= POnly cookies to protect them from theft via XSS. The same mechanism is not= possible for localStorage. Overall, security folk say =E2=80=A2keep sensit= ive data out of localStorage=E2=80=A2 since one XSS and it's stolen. There = is also a huge body of work underway to make secure cookies even more so.

I'm not sure how this translates = to native apps.

--
Jim = Manico
@Manicode

On Sep 8, 2016, a= t 3:02 AM, Adam Lewis <adam.lewis@motorolasolutions.com> wrot= e:

Hi,

The WG is currently putting together best practic= es for native apps.  I would like to better understand the best practi= ces around ua-based-apps, especially as it relates to token storage.&n= bsp; I've read various blog posts about the preference between storing toke= ns in cookies vs.  Web Storage (localStorage/sessionStorage).&nbs= p; The current set of specs are rather silent on the matter, as it is more = of an implementation issue (but that is where most mistakes are made).

What is the = WG's guidance on this?
_____________= __________________________________
OAuth mai= ling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


------=_Part_1929561_2037331673.1473358500294-- From nobody Thu Sep 8 12:51:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3119112B047 for ; Thu, 8 Sep 2016 12:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKaG4RjZZ-6p for ; Thu, 8 Sep 2016 12:51:53 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FE712B02F for ; Thu, 8 Sep 2016 12:51:53 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id w87so21254506pfk.2 for ; Thu, 08 Sep 2016 12:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=xj09Majj4sDgfoiZ97kpJOfgDhtt1VXK4ONju/+v6p8=; b=IEyVcqvTUPoLD+Tex21S1roIsV3vjZEOKgL/Fg0gP4aCG/ZAhGIDYX3I8oq1cTknn+ z/3O+CHTprKUwyV1EjJFLfcmqtLOuh1WlW9+QbYoOYRxK+1AgoEvT0Z2TiUTumBp1jyB WTt3yGpZjnlZnXqhAldw+FodAdpObrQ9Am9W1KQ+Tbxy4oDxagQG9mFk9C4y4cV/Ac+1 Ww9Q2VlIIOEiuvuXUWvZjbpYp/qWqWZwObaZcdl2KhGur9kE2B8fzFNix5mcfEU8q6K7 CSEhpi/i20QgA4U8286jdB0NIRZhtfU+q5zLDsKm4HT6vOZLr2N64mgw6G2F6/TfZmE9 cBvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xj09Majj4sDgfoiZ97kpJOfgDhtt1VXK4ONju/+v6p8=; b=AepCaD4saMDvsUSPucFellFbKuzQ6C4MEqxze7zfZRLAvdvOWoYRDrpSL1nBcjRohw joOI/7BKfDrIXCY/3fa2WhFwdKNJSq4fwO7pjq4LcmjswZroxbeg/jcAME2Pz4rXsf3m AQLXf4SKXCQ9fcWu65SkTBOqmSlWMoFrGQGltdXwEF4GZKbryPvo4vTIzxKzVnkWs9nQ ls6phQhVcOYPwT9qXYK8rlb0Q8/080ajwEluFfHyICneBnA5qZgMjffMZUEdZF4yRP5m b6BmlI6kvYmceyWzWmtMqbcIJilmsp+e8KWW1Hkti5TKnYo+N/un3U3uS8Rje542Xrv1 D3AA== X-Gm-Message-State: AE9vXwP2ABdOFfwymRhaBgrxvtTXB4PvJPpnibONusM1CzCYbIbSNHjLK35japCBICyxEW+J X-Received: by 10.98.106.65 with SMTP id f62mr2423231pfc.107.1473364312518; Thu, 08 Sep 2016 12:51:52 -0700 (PDT) Received: from heembo.local ([2605:e000:112b:c167:3ccb:e369:74b0:50fc]) by smtp.googlemail.com with ESMTPSA id px7sm6490310pac.41.2016.09.08.12.51.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 12:51:51 -0700 (PDT) To: Oleg Gryb , Adam Lewis References: <632483756.1929562.1473358500330@mail.yahoo.com> From: Jim Manico Message-ID: <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com> Date: Thu, 8 Sep 2016 09:51:48 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <632483756.1929562.1473358500330@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------465714FFA2F34DCCEA9FC0DF" Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 19:51:55 -0000 This is a multi-part message in MIME format. --------------465714FFA2F34DCCEA9FC0DF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies. In a browser environment, this is only true when you need to make cross domain requests or are using cookie data for something other than session state. If your current page origin and the page you are requesting are the same, then your cookies can be HTTPOnly without impacting functionality. If you need additional cookies for other things that need to be accessed via JS, use a separate cookie. So sure, there are a few workflows in OAuth where you need to access "cookie data" from JS and HTTPOnly is not viable. But there are a few where it is viable. I don't think it's as simple as "we need to talk to cookie data via JS all the time.". Aloha, Jim On 9/8/16 8:15 AM, Oleg Gryb wrote: > Jim, > > It's outdated a bit. Since SPA is a new normal now, it becomes > extremely difficult to enforce HTTPOnly flag, because JS needs access > to secrets including those stored in cookies. 5-10 years ago I would > always enforce HTTPOnly and now - I can't. > > Thanks, > Oleg. > > -------------------------------------------------------------------= ----- > *From:* Jim Manico > *To:* Adam Lewis > *Cc:* OAuth WG > *Sent:* Thursday, September 8, 2016 10:45 AM > *Subject:* Re: [OAUTH-WG] best practices for implicit grant / > token storage > > In the web world, cookies for session identifiers are much safer - > since we can use HTTPOnly cookies to protect them from theft via > XSS. The same mechanism is not possible for localStorage. Overall, > security folk say =E2=80=A2keep sensitive data out of localStorage=E2= =80=A2 since > one XSS and it's stolen. There is also a huge body of work > underway to make secure cookies even more so. > > I'm not sure how this translates to native apps. > > -- > Jim Manico > @Manicode > > On Sep 8, 2016, at 3:02 AM, Adam Lewis > > wrote: > >> Hi, >> >> The WG is currently putting together best practices for native >> apps. I would like to better understand the best practices >> around ua-based-apps, especially as it relates to token storage.=20 >> I've read various blog posts about the preference between storing >> tokens in cookies vs. Web Storage >> (localStorage/sessionStorage). The current set of specs are >> rather silent on the matter, as it is more of an implementation >> issue (but that is where most mistakes are made). >> >> What is the WG's guidance on this? >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Jim Manico Manicode Security https://www.manicode.com --------------465714FFA2F34DCCEA9FC0DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

> Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies.

In a browser environment, this is only true when you need to make cross domain requests or are using cookie data for something other than session state.

If your current page origin and the page you are requesting are the same, then your cookies can be HTTPOnly without impacting functionality. If you need additional cookies for other things that need to be accessed via JS, use a separate cookie.

So sure, there are a few workflows in OAuth where you need to access "cookie data" from JS and HTTPOnly is not viable. But there are a few where it is viable. I don't think it's as simple as "we need to talk to cookie data via JS all the time.".

Aloha, Jim

On 9/8/16 8:15 AM, Oleg Gryb wrote:
Jim,

It's outdated a bit. Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies. 5-10 years ago I would always enforce HTTPOnly and now - I can't.

Thanks,
Oleg.
From: Jim Manico <jim@manicode.com>
To: Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 10:45 AM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

In the web world, cookies for session identifiers are much safer - since we can use HTTPOnly cookies to protect them from theft via XSS. The same mechanism is not possible for localStorage. Overall, security folk say •keep sensitive data out of localStorage• since one XSS and it's stolen. There is also a huge body of work underway to make secure cookies even more so.

I'm not sure how this translates to native apps.

--
Jim Manico
@Manicode

On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Hi,

The WG is currently putting together best practices for native apps.  I would like to better understand the best practices around ua-based-apps, especially as it relates to token storage.  I've read various blog posts about the preference between storing tokens in cookies vs.  Web Storage (localStorage/sessionStorage).  The current set of specs are rather silent on the matter, as it is more of an implementation issue (but that is where most mistakes are made).

What is the WG's guidance on this?
_______________________________________________
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



-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------465714FFA2F34DCCEA9FC0DF-- From nobody Thu Sep 8 13:20:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F17812B04C for ; Thu, 8 Sep 2016 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.227 X-Spam-Level: X-Spam-Status: No, score=-4.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw3jwVvomkVA for ; Thu, 8 Sep 2016 13:20:05 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (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 49666128B38 for ; Thu, 8 Sep 2016 13:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1473366004; bh=5U/zWg3X+a8Gi8ij84mJd/G+qHUWvE7dc0le63X+1Y8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=aKaJpOcOTO+9AbYyAnTgnJtLCl+GsQxXxjxAeJ7e/oe74ilb7cMT8QnTqp9IS0wuFJRQfsUS3sj18/LgXVikBnZT4Hn4hUEPG34SyIz5DKn2C7cVy1G8XVGiPM7g9Rb2Go6EsTVOUK9WFG1WJcgH+AgweCm9ECmaRzinfB2f7HzUII50tiLVrzU+aSrebBXaTJCxASiizcop6fWdzToZBFFDEpQfxGLII1Kbl7z0OmhqipxGnaznGT8DqAcCrAXWDVU9H2gtYfnrBK1Tni2J4w6mQ6kCriKyghAv/AQgDVTAnjpmma6bX6UlpC06xkLac8ahAZc77slTWXgpiBmobw== Received: from [98.139.170.180] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 08 Sep 2016 20:20:04 -0000 Received: from [98.139.212.203] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 08 Sep 2016 20:20:04 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 08 Sep 2016 20:20:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 314710.95691.bm@omp1012.mail.bf1.yahoo.com X-YMail-OSG: kA0hzYoVM1mWb8hd1J2evidxSRYf3.3PMzY4QIP8D4HsSeZGsTMQJIA5VlT1GP8 r4StA3FkAeIZw_yLAESwLVeohinucEu1CuV8SBC3Nl5A_Y3J16Hent16l_LpaoG9RJyGspC7Ahu_ b8SPa6UuchOuu06irtEdmNa5.eQ.CE9Z_Bw7QaYUy1dyxET0Ka0rfEjw.MKsOTqhCZxee3Sy9aBp CTj_o6BNhkkhFz3FDnDxH3Cq4ZQHQWc_PokhxRCxFeIpiZr.VY7QwgV0tUFZa1Jkd0P3Me14kp1H YNsosSP9eDAaHLqn4kgrwAK2Yvqyi29MF_bk4a8phlFWv1lAgKpknGZ5pj1KSSj_cbbdsYGlIkrM 1apLCN73qLECjLHcOR40Dfwj68OD4LEqmlncSMwxMq6aYqox_uVy5uFFvfDg4qWYxQMaWBAusUu1 KT7zGW9iALD2nnAtk9VDooofdnBQk436N9rgUHwyMUdSO1QUxeY.5Dh1dw6TinHf76hW1ddnmUCp Q64ct1tko6uRW6pNFYeQjqJ7uLESRM9Gh53Ij Received: from jws106182.mail.bf1.yahoo.com by sendmailws136.mail.bf1.yahoo.com; Thu, 08 Sep 2016 20:20:03 +0000; 1473366003.853 Date: Thu, 8 Sep 2016 20:20:03 +0000 (UTC) From: Oleg Gryb To: Jim Manico , Oleg Gryb , Adam Lewis Message-ID: <1013244548.1998164.1473366003274@mail.yahoo.com> In-Reply-To: <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com> References: <632483756.1929562.1473358500330@mail.yahoo.com> <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1998163_353565142.1473366003260" Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 20:20:07 -0000 ------=_Part_1998163_353565142.1473366003260 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In SPA/REST env session ID is not very useful, so it's *an* auth token or t= okens (not necessary OAuth one) that are stored in a cookie. It's used to g= et REST calls authenticated and yes, it usually runs in a multi-domain envs= (think about micro services architecture). It makes me think that the valu= e of HTTPOnly will continue diminishing, while the value of good cross-doma= in policies will increase. Just my opinion coming from my experience. I don= 't have big (or small) data available to confirm that. =C2=A0=20 =20 From: Jim Manico To: Oleg Gryb ; Adam Lewis =20 Cc: OAuth WG Sent: Thursday, September 8, 2016 12:51 PM Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage =20 > Since SPA is a new normal now, it becomes extremely difficult to enforce= HTTPOnly flag, because JS needs access to secrets including those stored i= n cookies. In a browser environment, this is only true when you need to mak= e cross domain requests or are using cookie data for something other than s= ession state. If your current page origin and the page you are requesting a= re the same, then your cookies can be HTTPOnly without impacting functional= ity. If you need additional cookies for other things that need to be access= ed via JS, use a separate cookie. So sure, there are a few workflows in OAu= th where you need to access "cookie data" from JS and HTTPOnly is not viabl= e. But there are a few where it is viable. I don't think it's as simple as = "we need to talk to cookie data via JS all the time.". Aloha, Jim On 9/8/16 8:15 AM, Oleg Gryb wrote: =20 Jim,=20 It's outdated a bit. Since SPA is a new normal now, it becomes extremely = difficult to enforce HTTPOnly flag, because JS needs access to secrets incl= uding those stored in cookies. 5-10 years ago I would always enforce HTTPOn= ly and now - I can't.=20 Thanks, Oleg. =20 From: Jim Manico To: Adam Lewis =20 Cc: OAuth WG Sent: Thursday, September 8, 2016 10:45 AM Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage =20 In the web world, cookies for session identifiers are much safer - since= we can use HTTPOnly cookies to protect them from theft via XSS. The same m= echanism is not possible for localStorage. Overall, security folk say =E2= =80=A2keep sensitive data out of localStorage=E2=80=A2 since one XSS and i= t's stolen. There is also a huge body of work underway to make secure cooki= es even more so.=20 I'm not sure how this translates to native apps. =20 -- Jim Manico @Manicode =20 On Sep 8, 2016, at 3:02 AM, Adam Lewis = wrote: =20 =20 Hi,=20 The WG is currently putting together best practices for native apps.=C2= =A0 I would like to better understand the best practices around ua-based-ap= ps, especially as it relates to token=C2=A0storage.=C2=A0 I've read variou= s blog posts about the preference between storing tokens in cookies vs.=C2= =A0=C2=A0Web Storage (localStorage/sessionStorage).=C2=A0 The current set o= f specs are rather silent on the matter, as it is more of an implementatio= n issue (but that is where most mistakes are made).=20 What is the WG's guidance on this? =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 --=20 Jim Manico Manicode Security https://www.manicode.com=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 ------=_Part_1998163_353565142.1473366003260 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ------=_Part_1998163_353565142.1473366003260-- From nobody Thu Sep 8 14:07:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD0112B157 for ; Thu, 8 Sep 2016 14:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvECeCt2-Y3l for ; Thu, 8 Sep 2016 14:07:40 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFEF12B0B2 for ; Thu, 8 Sep 2016 14:07:39 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id w87so21788317pfk.2 for ; Thu, 08 Sep 2016 14:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=DRjL1pD2QwVAtzQxhHmQvvOenxvmt2366JKs23LaDKQ=; b=p53anCpWrNQhmHC1168sYlJ2wtOqve+6h9L0l1Ib+ucIu4BlZ81EYRvVxk34IQW2ab xgJum8PfKH4d9rBsm50QbUQ22S27ZCcn/wjUbzYnlpCRUiquBNiwUUnOCFLe7dltVbRA fnG6aGjO3cxqIDx21fUQKXhN7S9Lu/rFAi3aHDs9gCxYElao/1jpAv3btTToYwmrXC2M +ucECK4uQovb49FUcf4IkE1j3qpt0CS4f+4JrDzbIbmobPDKVY1aOKgKLBkJ6E6VeB1i CyXF506N6rTOVCp120Igz4IBKX5v5wG/xOPn9hnWZl8y5OydYFhgqvr2e/HZWYAqzOY+ bv0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=DRjL1pD2QwVAtzQxhHmQvvOenxvmt2366JKs23LaDKQ=; b=HY6KtY4orZ5SIQ+njaqdhCvQar3q75YVD/RZDYLjIGhEGG3OmspZ7bVaJNVlhPPpur S7onPlDsQLhkIkYSOeg0gNFjXCEaTOZJkWAIZPgFAQkpwRDgm6fG/Fpr9aupF82sVHSD 1wNaR0QQFgr9SVPZbEqNkziVD97U51zaLzjBVwk8qFTBEeVN2mqaFx6UyS+/vri8fwYu 2xv+52QLaEMExFXJVNHHGntJkI6sML0E0qlczF8djlRXn4Z8tBQ7y2Pg5M0hBz75Vj/8 pjnprTdYDqttGEDox1RuMWaeGsw+7Ej53brlEEbwlqnGr4PlgNSqLT4rOjUW8lxcQao7 MDIQ== X-Gm-Message-State: AE9vXwNT11EcXTXQU+d2CT2i8sUlhiKWdBnuFakb9SCHbtkuJHOCJe1nuOwJUl9xsIyMob6m X-Received: by 10.98.11.156 with SMTP id 28mr2974763pfl.165.1473368859167; Thu, 08 Sep 2016 14:07:39 -0700 (PDT) Received: from heembo.local ([2605:e000:112b:c167:3ccb:e369:74b0:50fc]) by smtp.googlemail.com with ESMTPSA id d200sm13258pfd.3.2016.09.08.14.07.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 14:07:38 -0700 (PDT) To: Oleg Gryb , Adam Lewis References: <632483756.1929562.1473358500330@mail.yahoo.com> <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com> <1013244548.1998164.1473366003274@mail.yahoo.com> From: Jim Manico Message-ID: <9265cef3-7859-cb09-ffe1-5d73a72af03e@manicode.com> Date: Thu, 8 Sep 2016 11:07:36 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1013244548.1998164.1473366003274@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------82156CB9E1BF9C41EE261B0E" Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 21:07:42 -0000 This is a multi-part message in MIME format. --------------82156CB9E1BF9C41EE261B0E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit +1 I think that's a very fair perspective. Putting sensitive data in LocalStorage is still a very bad idea. :) One XSS and gone. Maybe XSS is not a big deal in a native app, but it's death to Web apps. Aloha, Jim On 9/8/16 10:20 AM, Oleg Gryb wrote: > In SPA/REST env session ID is not very useful, so it's *an* auth token > or tokens (not necessary OAuth one) that are stored in a cookie. It's > used to get REST calls authenticated and yes, it usually runs in a > multi-domain envs (think about micro services architecture). It makes > me think that the value of HTTPOnly will continue diminishing, while > the value of good cross-domain policies will increase. Just my opinion > coming from my experience. I don't have big (or small) data available > to confirm that. > > > ------------------------------------------------------------------------ > *From:* Jim Manico > *To:* Oleg Gryb ; Adam Lewis > > *Cc:* OAuth WG > *Sent:* Thursday, September 8, 2016 12:51 PM > *Subject:* Re: [OAUTH-WG] best practices for implicit grant / > token storage > > > Since SPA is a new normal now, it becomes extremely difficult to > enforce HTTPOnly flag, because JS needs access to secrets > including those stored in cookies. > In a browser environment, this is only true when you need to make > cross domain requests or are using cookie data for something other > than session state. > If your current page origin and the page you are requesting are > the same, then your cookies can be HTTPOnly without impacting > functionality. If you need additional cookies for other things > that need to be accessed via JS, use a separate cookie. > So sure, there are a few workflows in OAuth where you need to > access "cookie data" from JS and HTTPOnly is not viable. But there > are a few where it is viable. I don't think it's as simple as "we > need to talk to cookie data via JS all the time.". > Aloha, Jim > On 9/8/16 8:15 AM, Oleg Gryb wrote: >> Jim, >> >> It's outdated a bit. Since SPA is a new normal now, it becomes >> extremely difficult to enforce HTTPOnly flag, because JS needs >> access to secrets including those stored in cookies. 5-10 years >> ago I would always enforce HTTPOnly and now - I can't. >> >> Thanks, >> Oleg. >> >> ------------------------------------------------------------------------ >> *From:* Jim Manico >> *To:* Adam Lewis >> >> *Cc:* OAuth WG >> *Sent:* Thursday, September 8, 2016 10:45 AM >> *Subject:* Re: [OAUTH-WG] best practices for implicit grant / >> token storage >> >> In the web world, cookies for session identifiers are much >> safer - since we can use HTTPOnly cookies to protect them >> from theft via XSS. The same mechanism is not possible for >> localStorage. Overall, security folk say •keep sensitive data >> out of localStorage• since one XSS and it's stolen. There is >> also a huge body of work underway to make secure cookies even >> more so. >> >> I'm not sure how this translates to native apps. >> >> -- >> Jim Manico >> @Manicode >> >> On Sep 8, 2016, at 3:02 AM, Adam Lewis >> > > wrote: >> >>> Hi, >>> >>> The WG is currently putting together best practices for >>> native apps. I would like to better understand the best >>> practices around ua-based-apps, especially as it relates to >>> token storage. I've read various blog posts about the >>> preference between storing tokens in cookies vs. Web >>> Storage (localStorage/sessionStorage). The current set of >>> specs are rather silent on the matter, as it is more of an >>> implementation issue (but that is where most mistakes are made). >>> >>> What is the WG's guidance on this? >>> _______________________________________________ >>> 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 >> >> > > -- > Jim Manico > Manicode Security > https://www.manicode.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Jim Manico Manicode Security https://www.manicode.com --------------82156CB9E1BF9C41EE261B0E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

+1 I think that's a very fair perspective.

Putting sensitive data in LocalStorage is still a very bad idea. :) One XSS and gone. Maybe XSS is not a big deal in a native app, but it's death to Web apps.

Aloha, Jim


On 9/8/16 10:20 AM, Oleg Gryb wrote:
In SPA/REST env session ID is not very useful, so it's *an* auth token or tokens (not necessary OAuth one) that are stored in a cookie. It's used to get REST calls authenticated and yes, it usually runs in a multi-domain envs (think about micro services architecture). It makes me think that the value of HTTPOnly will continue diminishing, while the value of good cross-domain policies will increase. Just my opinion coming from my experience. I don't have big (or small) data available to confirm that.  


From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>; Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 12:51 PM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

> Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies.
In a browser environment, this is only true when you need to make cross domain requests or are using cookie data for something other than session state.
If your current page origin and the page you are requesting are the same, then your cookies can be HTTPOnly without impacting functionality. If you need additional cookies for other things that need to be accessed via JS, use a separate cookie.
So sure, there are a few workflows in OAuth where you need to access "cookie data" from JS and HTTPOnly is not viable. But there are a few where it is viable. I don't think it's as simple as "we need to talk to cookie data via JS all the time.".
Aloha, Jim
On 9/8/16 8:15 AM, Oleg Gryb wrote:
Jim,

It's outdated a bit. Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies. 5-10 years ago I would always enforce HTTPOnly and now - I can't.

Thanks,
Oleg.
From: Jim Manico <jim@manicode.com>
To: Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 10:45 AM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

In the web world, cookies for session identifiers are much safer - since we can use HTTPOnly cookies to protect them from theft via XSS. The same mechanism is not possible for localStorage. Overall, security folk say •keep sensitive data out of localStorage• since one XSS and it's stolen. There is also a huge body of work underway to make secure cookies even more so.

I'm not sure how this translates to native apps.

--
Jim Manico
@Manicode

On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Hi,

The WG is currently putting together best practices for native apps.  I would like to better understand the best practices around ua-based-apps, especially as it relates to token storage.  I've read various blog posts about the preference between storing tokens in cookies vs.  Web Storage (localStorage/sessionStorage).  The current set of specs are rather silent on the matter, as it is more of an implementation issue (but that is where most mistakes are made).

What is the WG's guidance on this?
_______________________________________________
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



-- 
Jim Manico
Manicode Security
https://www.manicode.com

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



-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------82156CB9E1BF9C41EE261B0E-- From nobody Thu Sep 8 15:38:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3843912B098 for ; Thu, 8 Sep 2016 15:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAcCfdRhKYXj for ; Thu, 8 Sep 2016 15:38:36 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491DD128B44 for ; Thu, 8 Sep 2016 15:38:36 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z190so49381622qkc.3 for ; Thu, 08 Sep 2016 15:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=rcFalxI0ZCPsFleTsmf3j6tjZc3clIkI5PxpyK+I0dU=; b=c/lfaU/n36/NMPEXyLkCrBx3INoeWL7lVJDaIp45QBHKukVbZABcSDa+A0SxIHlfSU f1QmuZDG/5lrAcJPNPjLnSaVOVD1WMKURvHFH7fpgqFaEsi2nJigUl+Kw6gjFUASsqmV 52j+2CjdV9m0FTL+jLsOQr3vNtnngxrG9slUrO9gk10S57xoBR8i1Y1xW3ohJGLYtjyZ 6YTbMiKki7412FRmRLedRDzgb4W3fHPNcEOhmPBwDpIo+3l2HKWrL4+83MaimMPL4pc2 C1d0kspvQxtCKSciTYtTyj+8DO/q3UeCsZFFYr4bALLgi/yEh/fAXbOSnJV2IRXwGz5+ H2tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rcFalxI0ZCPsFleTsmf3j6tjZc3clIkI5PxpyK+I0dU=; b=L9v6/TaC1aB3+OexK3oD4cd7BHRd/H+IQSj7J33pzbxkpEElyUVy7LwfjvE9u5aZtu fryJJ9EwmR4Ke6GPlb47c/9v/iM/7e1dw7v2c4nbZENCoj5ZiSdVdMKlIwMZYmXBAFMd sqi7uifyQr+Q69r96N7O8lTB+PjYRXh0UHCa+rMXpDOsa/EskX+c1ujLvnOnC7YwKUqf aR1mNNO774SJlb9cpDEgcgmLIHGwxE5AGnnTb/fFqQdYckDZaeduIaiFH8fJZpKabnxw ZaBG+VuDJu/BBzAbJXy5RIbwbG5xLKWv7/3s8B8XKtfFiXOIf31EclwtUhLGG2R/oKAA VfPQ== X-Gm-Message-State: AE9vXwPif9usXayraKeQ1wkvXDYoHLjC0bUB04/jNRBe6Fkh8fAbbQbz1pmUkTjy1oZUoMi0 X-Received: by 10.55.99.17 with SMTP id x17mr372341qkb.261.1473374315165; Thu, 08 Sep 2016 15:38:35 -0700 (PDT) Received: from [192.168.8.100] ([181.202.19.154]) by smtp.gmail.com with ESMTPSA id a193sm178616qkc.46.2016.09.08.15.38.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Sep 2016 15:38:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7437DB45-8766-4A5E-B400-760E0381C9A4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <9265cef3-7859-cb09-ffe1-5d73a72af03e@manicode.com> Date: Thu, 8 Sep 2016 19:38:30 -0300 Message-Id: References: <632483756.1929562.1473358500330@mail.yahoo.com> <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com> <1013244548.1998164.1473366003274@mail.yahoo.com> <9265cef3-7859-cb09-ffe1-5d73a72af03e@manicode.com> To: Jim Manico X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 22:38:39 -0000 --Apple-Mail=_7437DB45-8766-4A5E-B400-760E0381C9A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It is an interesting discussion, indicating that perhaps a best = practices document is in order. I have had several people ask me about SPA using OAuth recently. Until we get the W3C to finish fetch and extend it for token binding, we = are going to have ongoing issues with bearer tokens in the browser and = where to store them. I don=E2=80=99t know that there is a perfect solution for bearer tokens, = but documenting the tradeoffs may be useful. John B. > On Sep 8, 2016, at 6:07 PM, Jim Manico wrote: >=20 > +1 I think that's a very fair perspective. >=20 > Putting sensitive data in LocalStorage is still a very bad idea. :) = One XSS and gone. Maybe XSS is not a big deal in a native app, but it's = death to Web apps. > Aloha, Jim >=20 > On 9/8/16 10:20 AM, Oleg Gryb wrote: >> In SPA/REST env session ID is not very useful, so it's *an* auth = token or tokens (not necessary OAuth one) that are stored in a cookie. = It's used to get REST calls authenticated and yes, it usually runs in a = multi-domain envs (think about micro services architecture). It makes me = think that the value of HTTPOnly will continue diminishing, while the = value of good cross-domain policies will increase. Just my opinion = coming from my experience. I don't have big (or small) data available to = confirm that. =20 >>=20 >>=20 >> From: Jim Manico >> To: Oleg Gryb ; Adam Lewis = = =20 >> Cc: OAuth WG >> Sent: Thursday, September 8, 2016 12:51 PM >> Subject: Re: [OAUTH-WG] best practices for implicit grant / token = storage >>=20 >> > Since SPA is a new normal now, it becomes extremely difficult to = enforce HTTPOnly flag, because JS needs access to secrets including = those stored in cookies. >> In a browser environment, this is only true when you need to make = cross domain requests or are using cookie data for something other than = session state. >> If your current page origin and the page you are requesting are the = same, then your cookies can be HTTPOnly without impacting functionality. = If you need additional cookies for other things that need to be accessed = via JS, use a separate cookie. >> So sure, there are a few workflows in OAuth where you need to access = "cookie data" from JS and HTTPOnly is not viable. But there are a few = where it is viable. I don't think it's as simple as "we need to talk to = cookie data via JS all the time.". >> Aloha, Jim >> On 9/8/16 8:15 AM, Oleg Gryb wrote: >>> Jim, >>>=20 >>> It's outdated a bit. Since SPA is a new normal now, it becomes = extremely difficult to enforce HTTPOnly flag, because JS needs access to = secrets including those stored in cookies. 5-10 years ago I would always = enforce HTTPOnly and now - I can't. >>>=20 >>> Thanks, >>> Oleg. >>> From: Jim Manico >>> To: Adam Lewis = =20 >>> Cc: OAuth WG >>> Sent: Thursday, September 8, 2016 10:45 AM >>> Subject: Re: [OAUTH-WG] best practices for implicit grant / token = storage >>>=20 >>> In the web world, cookies for session identifiers are much safer - = since we can use HTTPOnly cookies to protect them from theft via XSS. = The same mechanism is not possible for localStorage. Overall, security = folk say =E2=80=A2keep sensitive data out of localStorage=E2=80=A2 since = one XSS and it's stolen. There is = also a huge body of work underway to make secure cookies even more = so. >>>=20 >>> I'm not sure how this translates to native apps. >>>=20 >>> -- >>> Jim Manico >>> @Manicode >>>=20 >>> On Sep 8, 2016, at 3:02 AM, Adam Lewis = > wrote: >>>=20 >>>> Hi, >>>>=20 >>>> The WG is currently putting together best practices for native = apps. I would like to better understand the best practices around = ua-based-apps, especially as it relates to token storage. I've read = various blog posts about the preference between storing tokens in = cookies vs. Web Storage (localStorage/sessionStorage). The current set = of specs are rather silent on the matter, as it is more of an = implementation issue (but that is where most mistakes are made). >>>>=20 >>>> What is the WG's guidance on this? >>>> _______________________________________________ >>>> 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 >>=20 >> --=20 >> Jim Manico >> Manicode Security >> https://www.manicode.com >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 > --=20 > Jim Manico > Manicode Security > https://www.manicode.com = _______________________________________________= > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7437DB45-8766-4A5E-B400-760E0381C9A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It is an interesting discussion, indicating that perhaps a = best practices document is in order.

I have had several people ask me about = SPA using OAuth recently.

Until we get the W3C to finish fetch and extend it for token = binding, we are going to have ongoing issues with bearer tokens in the = browser and where to store them.

I don=E2=80=99t know that there is a = perfect solution for bearer tokens, but documenting the tradeoffs may be = useful.

John = B.

On Sep 8, 2016, at 6:07 PM, Jim Manico <jim@manicode.com> = wrote:

=20 =20

+1 = I think that's a very fair perspective.

Putting = sensitive data in LocalStorage is still a very bad idea. :) One XSS and gone. Maybe XSS is not a big deal in a native app, but it's death to Web apps.

Aloha, Jim


On 9/8/16 10:20 AM, Oleg Gryb = wrote:
In SPA/REST env session ID is not very useful, so it's *an* auth token or tokens (not necessary OAuth one) that are stored in a cookie. It's used to get REST calls authenticated and yes, it usually runs in a multi-domain envs (think about micro services architecture). It makes me think that the value of HTTPOnly will continue diminishing, while the value of good cross-domain policies will increase. Just my opinion coming from my experience. I don't have big (or small) data available to confirm that.  


From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>; Adam Lewis <adam.lewis@motorolaso= lutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 12:51 PM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

> Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies.
In a browser environment, this is only true when you need to make cross domain requests or are using cookie data for something other than session state.
If your current page origin and = the page you are requesting are the same, then your cookies can be HTTPOnly without impacting functionality. If you need additional cookies for other things that need to be accessed via JS, use a separate cookie.
So sure, there are a few workflows in OAuth where you need to access "cookie data" from JS and HTTPOnly is not viable. But there are a few where it is viable. I don't think it's as simple as "we need to talk to cookie data via JS all the time.".
Aloha, Jim
On 9/8/16 8:15 AM, Oleg Gryb wrote:
Jim,

It's outdated a bit. Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies. 5-10 years ago I would always enforce HTTPOnly and now - I can't.

Thanks,
Oleg.
From: Jim Manico <jim@manicode.com>
To: Adam Lewis <adam.lewis@motorolaso= lutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 10:45 AM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

In the web world, cookies for session identifiers are much safer - since we can use HTTPOnly cookies to protect them from theft via XSS. The same mechanism is not possible for localStorage. Overall, security folk say =E2=80=A2keep sensitive data = out of localStorage=E2=80=A2 since = one XSS and it's stolen. There is also a huge body of work underway to make secure cookies even more so.

I'm not sure how this translates to native apps.

=
--
Jim = Manico
@Manicode

On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Hi,

The WG is currently putting together best practices for native apps.  = I would like to better understand the best practices around ua-based-apps, especially as it relates to = token storage.  I've read various blog posts about the preference between storing tokens in cookies vs.  Web = Storage = (localStorage/sessionStorage).  The current set of specs are rather silent on the matter, as it is more of an implementation issue (but that is where most mistakes are = made).

What is the WG's guidance on = this?
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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



--=20
Jim Manico
Manicode Security
https://www.manicode.com

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



--=20
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_7437DB45-8766-4A5E-B400-760E0381C9A4-- From nobody Thu Sep 8 15:51:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0278012B274 for ; Thu, 8 Sep 2016 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIF-wr-XJdYe for ; Thu, 8 Sep 2016 15:51:47 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57328128B44 for ; Thu, 8 Sep 2016 15:51:47 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id p64so22590677pfb.1 for ; Thu, 08 Sep 2016 15:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=+MAQrqC0lz/eWm0PAgY1P+crZe1xO3i7R0aQ37nbc1Q=; b=BAUwvTI7Zo/An7nMPBAMIyJYmMZkf4phKz7X4p/Yis6D2tjN4qEzKJkjmghsYoIadd ljkUb6ervi2ueErIyugiQKGKeQ5v+eRg24dfG/wbGQPWXvVEQNxscE2gd5V8/msWvZyA NOu0bEqmAuFxPtGf/hHIjOKKSM7gO/QIhlW/kW3UVEHD1r6izFEH3jIonXcP3HPa1UZu mKddI9ZCg14quqPJB61KKNf8AvRBKLk6rNCVa0E3hkOk69qoCXNGb4POJfQl9nU0JRHx EcKInLzCZUEaQOU3flAGCkFZ6N+/CrZ5wGDFIl63nQWh13G9K7ywCg1ichcAUSq2CVfy G3UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=+MAQrqC0lz/eWm0PAgY1P+crZe1xO3i7R0aQ37nbc1Q=; b=OdRsTLwFbkyv2BVmESbOSzwzKrdbWUoQwOQUJMI0FjmzzNcoLG9I77DSIaNEgxr+1p arDkUrMbiVB7z+saXulyyVVR8Gn1qMS8DQ+4Sg/Cu89U2wlCk/wguXs+OQq+0iB+ct4i yVg6eSLZdvDntuOXHoFRGEqrCIR3hL6BCIhhbZ50MA5Jme6HoDfNB2xhfNUlbMrxXDVu k6hVBHTcIEQ1OiIf5ZxoslEkcjEPqjPWnFMs7N64TX9kI6GQ/VGtEylxB20pA1QKHhnF epkYktRtirJZ2Kyh+iAm+PjxEht+nvYgbpgTDEejmnzJNZIFL2Jp9AUBZHROyIjxypoG 7Nmg== X-Gm-Message-State: AE9vXwMGDtvp5pS/sPnImwf5Bl//oVvAoermNa1NrDWk5I2WiZfnm8yyYKy+Lz4GQhzcYg5Z X-Received: by 10.98.29.8 with SMTP id d8mr730471pfd.142.1473375106544; Thu, 08 Sep 2016 15:51:46 -0700 (PDT) Received: from heembo.local ([2605:e000:112b:c167:3ccb:e369:74b0:50fc]) by smtp.googlemail.com with ESMTPSA id vy9sm221593pab.22.2016.09.08.15.51.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 15:51:44 -0700 (PDT) To: John Bradley References: <632483756.1929562.1473358500330@mail.yahoo.com> <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com> <1013244548.1998164.1473366003274@mail.yahoo.com> <9265cef3-7859-cb09-ffe1-5d73a72af03e@manicode.com> From: Jim Manico Message-ID: <3be430fb-afe7-ab94-1369-7fcdfdedec0b@manicode.com> Date: Thu, 8 Sep 2016 12:51:41 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CF5787419ED16CAF623550F6" Archived-At: Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 22:51:50 -0000 This is a multi-part message in MIME format. --------------CF5787419ED16CAF623550F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit +1000 on a OAuth Security Best Practices document. I'd be happy to review or help some. I think right now the answer is: keep away from implicit grants and do not store bearer tokens in the browser. Instead, use the authorization code grant which only exposes bearer tokens intra-server. For /*web apps*/, I feel the only good place to store authentication, session or token information is in a HTTPOnly flagged cookie to keep JS away from sensitive information. Aloha, Jim On 9/8/16 12:38 PM, John Bradley wrote: > It is an interesting discussion, indicating that perhaps a best > practices document is in order. > > I have had several people ask me about SPA using OAuth recently. > > Until we get the W3C to finish fetch and extend it for token binding, > we are going to have ongoing issues with bearer tokens in the browser > and where to store them. > > I don’t know that there is a perfect solution for bearer tokens, but > documenting the tradeoffs may be useful. > > John B. > >> On Sep 8, 2016, at 6:07 PM, Jim Manico > > wrote: >> >> +1 I think that's a very fair perspective. >> >> Putting sensitive data in LocalStorage is still a very bad idea. :) >> One XSS and gone. Maybe XSS is not a big deal in a native app, but >> it's death to Web apps. >> >> Aloha, Jim >> >> >> On 9/8/16 10:20 AM, Oleg Gryb wrote: >>> In SPA/REST env session ID is not very useful, so it's *an* auth >>> token or tokens (not necessary OAuth one) that are stored in a >>> cookie. It's used to get REST calls authenticated and yes, it >>> usually runs in a multi-domain envs (think about micro services >>> architecture). It makes me think that the value of HTTPOnly will >>> continue diminishing, while the value of good cross-domain policies >>> will increase. Just my opinion coming from my experience. I don't >>> have big (or small) data available to confirm that. >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Jim Manico >>> *To:* Oleg Gryb ; Adam Lewis >>> >>> *Cc:* OAuth WG >>> *Sent:* Thursday, September 8, 2016 12:51 PM >>> *Subject:* Re: [OAUTH-WG] best practices for implicit grant / >>> token storage >>> >>> > Since SPA is a new normal now, it becomes extremely difficult >>> to enforce HTTPOnly flag, because JS needs access to secrets >>> including those stored in cookies. >>> In a browser environment, this is only true when you need to >>> make cross domain requests or are using cookie data for >>> something other than session state. >>> If your current page origin and the page you are requesting are >>> the same, then your cookies can be HTTPOnly without impacting >>> functionality. If you need additional cookies for other things >>> that need to be accessed via JS, use a separate cookie. >>> So sure, there are a few workflows in OAuth where you need to >>> access "cookie data" from JS and HTTPOnly is not viable. But >>> there are a few where it is viable. I don't think it's as simple >>> as "we need to talk to cookie data via JS all the time.". >>> Aloha, Jim >>> On 9/8/16 8:15 AM, Oleg Gryb wrote: >>>> Jim, >>>> >>>> It's outdated a bit. Since SPA is a new normal now, it becomes >>>> extremely difficult to enforce HTTPOnly flag, because JS needs >>>> access to secrets including those stored in cookies. 5-10 years >>>> ago I would always enforce HTTPOnly and now - I can't. >>>> >>>> Thanks, >>>> Oleg. >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Jim Manico >>>> *To:* Adam Lewis >>>> >>>> *Cc:* OAuth WG >>>> *Sent:* Thursday, September 8, 2016 10:45 AM >>>> *Subject:* Re: [OAUTH-WG] best practices for implicit grant >>>> / token storage >>>> >>>> In the web world, cookies for session identifiers are much >>>> safer - since we can use HTTPOnly cookies to protect them >>>> from theft via XSS. The same mechanism is not possible for >>>> localStorage. Overall, security folk say •keep sensitive >>>> data out of localStorage• since one XSS and it's stolen. >>>> There is also a huge body of work underway to make secure >>>> cookies even more so. >>>> >>>> I'm not sure how this translates to native apps. >>>> >>>> -- >>>> Jim Manico >>>> @Manicode >>>> >>>> On Sep 8, 2016, at 3:02 AM, Adam Lewis >>>> >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> The WG is currently putting together best practices for >>>>> native apps. I would like to better understand the best >>>>> practices around ua-based-apps, especially as it relates >>>>> to token storage. I've read various blog posts about the >>>>> preference between storing tokens in cookies vs. Web >>>>> Storage (localStorage/sessionStorage). The current set of >>>>> specs are rather silent on the matter, as it is more of an >>>>> implementation issue (but that is where most mistakes are >>>>> made). >>>>> >>>>> What is the WG's guidance on this? >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> -- >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> -- >> Jim Manico >> Manicode Security >> https://www.manicode.com >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Jim Manico Manicode Security https://www.manicode.com --------------CF5787419ED16CAF623550F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

+1000 on a OAuth Security Best Practices document. I'd be happy to review or help some.

I think right now the answer is: keep away from implicit grants and do not store bearer tokens in the browser. Instead, use the authorization code grant which only exposes bearer tokens intra-server.

For web apps, I feel the only good place to store authentication, session or token information is in a HTTPOnly flagged cookie to keep JS away from sensitive information.

Aloha, Jim


On 9/8/16 12:38 PM, John Bradley wrote:
It is an interesting discussion, indicating that perhaps a best practices document is in order.

I have had several people ask me about SPA using OAuth recently.

Until we get the W3C to finish fetch and extend it for token binding, we are going to have ongoing issues with bearer tokens in the browser and where to store them.

I don’t know that there is a perfect solution for bearer tokens, but documenting the tradeoffs may be useful.

John B.

On Sep 8, 2016, at 6:07 PM, Jim Manico <jim@manicode.com> wrote:

+1 I think that's a very fair perspective.

Putting sensitive data in LocalStorage is still a very bad idea. :) One XSS and gone. Maybe XSS is not a big deal in a native app, but it's death to Web apps.

Aloha, Jim


On 9/8/16 10:20 AM, Oleg Gryb wrote:
In SPA/REST env session ID is not very useful, so it's *an* auth token or tokens (not necessary OAuth one) that are stored in a cookie. It's used to get REST calls authenticated and yes, it usually runs in a multi-domain envs (think about micro services architecture). It makes me think that the value of HTTPOnly will continue diminishing, while the value of good cross-domain policies will increase. Just my opinion coming from my experience. I don't have big (or small) data available to confirm that.  


From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>; Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 12:51 PM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

> Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies.
In a browser environment, this is only true when you need to make cross domain requests or are using cookie data for something other than session state.
If your current page origin and the page you are requesting are the same, then your cookies can be HTTPOnly without impacting functionality. If you need additional cookies for other things that need to be accessed via JS, use a separate cookie.
So sure, there are a few workflows in OAuth where you need to access "cookie data" from JS and HTTPOnly is not viable. But there are a few where it is viable. I don't think it's as simple as "we need to talk to cookie data via JS all the time.".
Aloha, Jim
On 9/8/16 8:15 AM, Oleg Gryb wrote:
Jim,

It's outdated a bit. Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies. 5-10 years ago I would always enforce HTTPOnly and now - I can't.

Thanks,
Oleg.
From: Jim Manico <jim@manicode.com>
To: Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 10:45 AM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

In the web world, cookies for session identifiers are much safer - since we can use HTTPOnly cookies to protect them from theft via XSS. The same mechanism is not possible for localStorage. Overall, security folk say •keep sensitive data out of localStorage• since one XSS and it's stolen. There is also a huge body of work underway to make secure cookies even more so.

I'm not sure how this translates to native apps.

--
Jim Manico
@Manicode

On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Hi,

The WG is currently putting together best practices for native apps.  I would like to better understand the best practices around ua-based-apps, especially as it relates to token storage.  I've read various blog posts about the preference between storing tokens in cookies vs.  Web Storage (localStorage/sessionStorage).  The current set of specs are rather silent on the matter, as it is more of an implementation issue (but that is where most mistakes are made).

What is the WG's guidance on this?
_______________________________________________
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



-- 
Jim Manico
Manicode Security
https://www.manicode.com

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



-- 
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------CF5787419ED16CAF623550F6-- From nobody Thu Sep 8 15:52:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A92612B274 for ; Thu, 8 Sep 2016 15:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9-XKhY6gHiB for ; Thu, 8 Sep 2016 15:52:39 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0094.outbound.protection.outlook.com [104.47.38.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48550128B44 for ; Thu, 8 Sep 2016 15:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=70bdEIT64mcbcTd+2tZurpHXnuqYTO4LXoG+j0Q0P0E=; b=M75Jf3b652uyg4zY/HU3qatQZwy9yGHZQQJgHfGlv/7w7ZeF1zgmq1a80yxRBFl63MrHa4bh8WWh5LEg+tiJCrCG8QT2kZuGu06Xu8kzAehXR9MKGObwh8D0FZ7WAIASqPoVlSM+bZIucy71x6msg7IFRCQ8QRvW/ZIXCde81Us= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by SN1PR0301MB2032.namprd03.prod.outlook.com (10.163.226.30) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Thu, 8 Sep 2016 22:52:37 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.0609.016; Thu, 8 Sep 2016 22:52:37 +0000 From: Anthony Nadalin To: Justin Richer , Brian Campbell Thread-Topic: [OAUTH-WG] Following up on token exchange use case Thread-Index: AQHR7C9prJ4IuzegbEWdu8G0DH4usKBbprEAgAHk64CAErLh8A== Date: Thu, 8 Sep 2016 22:52:37 +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=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8::382] x-ms-office365-filtering-correlation-id: a8d54361-1d16-48f1-37d1-08d3d83ad479 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB2032; 6:q8ZlaHg43Jcbqvt9YSJtXCiECVhk5LSNYVDw8qLAq3BIWYwYEBbbaMR+Ir+uaErWw56T3rrDoCiNmTHNlh/QcxZzgxM4DrCfnZjQyzdKd2L//5PU+0iOZjwjQwDSFRsw37UfrX5vvELdQK2nfSiXMkdnAsRdTN/ZWxqeHrllUxdnOykZRXi8uJR9DB6cSd73dIUc4k89Xkbd+l3wa5zfxG/WXPtL0our1grqjKLSY5PSAYpw+4hAXicTHPadmL7EGrmAYVlk8mUGbegmSN4LwrH8V3/Rcgf+gEXmtFP9hfUfPM/amhmcAi/SmLHer1FQ+aVSWLd3jqKKvhlFfKDAfQ==; 5:mQDEO3bVRwK4gk/w8iUmaVJTGffKj8adw/Wb0N73TapJhJ3enXFDqWbSiNBiz+btQpF3gLmzydBOsCsg7OcH/Tm/dCXGlpO0NZyMcF5bBqqBdBV+CxPgVEeVyIPmNtBkdwViDYgcj0NxneuRg5oZYw==; 24:Py0cOVru+7yHEfiy5pbNpIGSxEShHlFJxdUMAHujg8brAY9XAmrEkR+oyP1m3HiBMbE8smvVbW0qX8mRwXVSMX80iG/A+6kL8qpKi/NUPKs=; 7:DXTC1ZK41PuIkDP+4Qa+4pb1twFjd6zggt9j7VKM6JxAH4LE1hbVGQGvtWnFDC25Gt1OjWTIQ0ADbVw2SFGNWctJpTGplESMlkYn4Q8Y2hXHCE/6Cbz2NU/WvY3itBeKrUyEFh8Re15mSwFqx7erbqvonGX4jvg85aYIQodkpdRMawi5ISdC9j/U1myX73b8SAFFEc56Bb3c1Tjak2SFGQ6kksG5v5fyuxfBRjF+At5QPFLjGR/V0QMflFTDC8UI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB2032; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB2032; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB2032; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(199003)(189002)(19609705001)(4326007)(790700001)(54356999)(6116002)(102836003)(76176999)(586003)(33656002)(50986999)(97736004)(5001770100001)(76576001)(8676002)(3660700001)(189998001)(8936002)(5002640100001)(15975445007)(3280700002)(8990500004)(7696004)(87936001)(2171001)(16236675004)(77096005)(2906002)(9686002)(11100500001)(10290500002)(86362001)(86612001)(5660300001)(68736007)(10090500001)(19580405001)(101416001)(122556002)(106356001)(2900100001)(10400500002)(19617315012)(81166006)(105586002)(5005710100001)(19580395003)(99286002)(106116001)(7906003)(81156014)(74316002)(19300405004)(7846002)(92566002)(2950100001)(19625215002)(7736002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB2032; H:SN1PR0301MB2029.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB2029A0BBD8C0E7AB3DB01A45A6FB0SN1PR0301MB2029_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2016 22:52:37.1766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB2032 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Following up on token exchange use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 22:52:42 -0000 --_000_SN1PR0301MB2029A0BBD8C0E7AB3DB01A45A6FB0SN1PR0301MB2029_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpbmdzIGhhdmUgZ290dGVuIHNvIG11ZGRsZWQgbm90IHN1cmUgd2hlcmUgdG8gYmVnaW4sIHRo ZSBvcmlnaW5hbCBnb2FsIG9mIHRoaXMgZHJhZnQgd2FzIHRvIHByb3ZpZGUgdGhlIGZ1bmN0aW9u IHRoYXQgd2UgdXNlIGluIGRhaWx5IGhpZ2ggdm9sdW1lIHByb2R1Y3Rpb24gb2YgV1MtVHJ1c3Qg YXMgd2UgdHJhbnNpdGlvbiB0byBPYXV0aC4gIFdTLVRydXN0IHByb3ZpZGVkIG1hbnkgb3B0aW9u cywgb25lIHdhcyBBY3RBcyBhbmQgdGhlIG90aGVyIHdhcyBPbkJlaGFsZk9mLCB0aGVzZSB3ZXJl IDIgZGlzdGluY3QgZnVuY3Rpb25zIGJ1dCBjb3VsZCBiZSBjb21iaW5lZCAoYW5kIHRodXMgdGhl IHJlc3VsdHMgYXJlIG9mIGEgY29tcG9zaXRlIG5hdHVyZSkuIFRoZXJlIHdlcmUgYWxzbyBvdGhl ciBvcHRpb25zIGxpa2UgZGVsZWdhdGVUbywgRm9yd2FyZGFibGUgYW5kIERlbGVnYXRhYmxlLiBT byB3ZSBoYXZlIHVzZSBjYXNlcyBmb3IgYWxsIHRoZXNlLg0KDQpTbyB3ZSBoYXZlIHN0cmFpZ2h0 IGZvcndhcmQgc2NlbmFyaW9zIGZvciAoMSkgYSB0b2tlbiByZXF1ZXN0IHRvIGJlIG9uIGJlaGFs ZiBvZiBhIGdpdmVuL3NwZWNpZmllZCB0b2tlbiwgd2UgYWxzbyBoYXZlIGEgc3RyYWlnaHQgZm9y d2FyZCBzY2VuYXJpbyBmb3IgKDIpIHJlcXVlc3RpbmcgYSB0b2tlbiBiYXNlZCB1cG9uIGEgc3Bl Y2lmaWMgdG9rZW4uIFdlIGFsc28gaGF2ZSBjb21wbGV4IHNjZW5hcmlvcyBmb3IgY29tYmluaW5n IHRoZSBzZW1hbnRpY3Mgb2YgYm90aCAgKDEpIGFuZCAoMikgd2hlcmUgdGhlIHRva2VuIHJlcXVl c3QgaXMgb24gYmVoYWxmIG9mIGEgc3BlY2lmaWMgdG9rZW4gYW5kIHRoZSByZXF1ZXN0IGlzIGJh c2VkIHVwb24gYSBzcGVjaWZpYyB0b2tlbiwgdGhpcyBoYXBwZW5lZCBhIGxvdCBpbiBvdXIgc2Vy dmVyIHRvIHNlcnZlciBzY2VuYXJpb3MgZm9yIGFjY2VzcyB0byBiYWNrZW5kIGRvY3VtZW50cyBh bmQgc2VydmljZXMuIFdoZXJlIHdlIGhhdmUgY2hhaW5lZCBzZXJ2aWNlcyB0aGlzIGlzIHdoZXJl IHRoZSBkZWxlZ2F0ZVRvLCBGb3J3YXJkYWJsZSBhbmQgRGVsZWdhdGFibGUgb3B0aW9ucyBjb21l IGludG8gdGhlIHNjZW5hcmlvLg0KDQpUaGUgd2F5IHRoYXQgdGhpcyBjdXJyZW50IHNwZWNpZmlj YXRpb24gaXMgc3RydWN0dXJlZCBhbmQgd3JpdHRlbiB0aGUgU3ViamVjdCBpcyBhbHdheXMgcmVx dWlyZWQgd2hpY2ggaXMgYSBub3QgYSBnb29kIHRoaW5nIHNpbmNlIHRoZXJlIG1heSBub3QgYmUg YSBzdWJqZWN0LCBhcyBiYXNpYyB0b2tlbiByZXF1ZXN0cyBkb27igJl0IGhhdmUgdG8gaGF2ZSBz dWJqZWN0cyAoanVzdCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyksIHRodXMgeW91IGNhbuKA mXQgZ2V0IHRoZSBzZW1hbnRpY3Mgb2YgKDIpIHdpdGhvdXQgKDEpLiBOb3cgdGhlIHNlbWFudGlj cyBvZiBjb21iaW5nICgxKSBhbmQgKDIpIHNlZW0gdG8gYmUgbm90IHVuZGVyc3Rvb2QgYW5kIHdh bnRpbmcgdG8gYmUgcmVtb3ZlZC4NCg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyDQpTZW50OiBTYXR1cmRheSwg QXVndXN0IDI3LCAyMDE2IDM6MjYgUE0NClRvOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb20+DQpDYzogPG9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBGb2xsb3dpbmcgdXAgb24gdG9rZW4gZXhjaGFuZ2UgdXNl IGNhc2UNCg0KTm8gb2JqZWN0aW9ucy4gU2ltcGxpZmljYXRpb24gaXMgYmV0dGVyLCBhbmQgdGhp cyBzcGVjIGlzIGFscmVhZHkgZmFpcmx5IGNvbnZvbHV0ZWQgd2l0aCBhbGwgdGhlIG9wdGlvbnMg dHVybmVkIG9uLg0KDQog4oCUIEp1c3Rpbg0KDQpPbiBBdWcgMjYsIDIwMTYsIGF0IDE6MzAgUE0s IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCg0KTG9va2luZyBmb3IgdHdvIHRoaW5ncyBo ZXJlOg0KMSkgQW55IG9iamVjdGlvbnMgdG8gcmVtb3ZpbmcgdGhlIHdhbnRfY29tcG9zaXRlIHJl cXVlc3QgcGFyYW1ldGVyPyBQbGVhc2UgZXhwbGFpbiwgaWYgc28uIEkgcGxhbiB0byByZW1vdmUg aXQgaW4gdGhlIG5leHQgZHJhZnQgYmFycmluZyBhbiBvdXRwb3VyaW5nIG9mIHN1cHBvcnQgdG8g a2VlcCBpdC4NCjIpIFRvbnkgdG8gZXhwbGFpbiBoaXMgdXNlIGNhc2UgYW5kIGRlc2NyaWJlIHdo YXQgY2hhbmdlcyB3b3VsZCBiZSBuZWVkZWQgdG8gYWNjb21tb2RhdGUgaXQuDQoNCk9uIE1vbiwg QXVnIDEsIDIwMTYgYXQgMjowMCBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KRHVy aW5nIHRoZSBtZWV0aW5nIGluIEJlcmxpbiBUb255IHZvaWNlZCBjb25jZXJuIGFib3V0IGEgdXNl IGNhc2UgaGUgaGFkIGZvciB0b2tlbiBleGNoYW5nZS4gSG9uZXN0bHksIGl0J3Mgc3RpbGwgbm90 IGVudGlyZWx5IGNsZWFyIHRvIG1lIHdoYXQgdGhhdCB1c2UgY2FzZSBpcyBvciB3aGF0IHdvdWxk IG5lZWQgdG8gY2hhbmdlIGluIHN1cHBvcnQgb2YgaXQuIEknZCBsaWtlIHRvIGJldHRlciB1bmRl cnN0YW5kIHRoZSB1c2UgY2FzZSBhbmQgc2VlIGlmIGl0J3Mgc29tZXRoaW5nIHRoYXQgY2FuIHJl YXNvbmFibHkgYmUgYWNjb21tb2RhdGVkIHdpdGggVG9rZW4gRXhjaGFuZ2UuIER1cmluZyB0aGUg bWVldGluZyBUb255IHJlZmVycmVkIGJhY2sgdG8gYW4gZWFybGllciBlbWFpbCB3aGVyZSBoZSBz YWlkLCAid2FudF9jb21wb3NpdGUgaXMgbm90IHJlYWxseSB0aGUgZWZmZWN0IHdlIGFyZSBsb29r aW5nIGZvciBzaW5jZSBpdCBwcm92aWRlcyBmb3IgYSBzaW5nbGUgdG9rZW4sIHRoZSB1c2UgY2Fz ZSB3ZSBoYXZlIGlzIHdoZXJlIHlvdSB3YW50IHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUgc3ViamVj dF90b2tlbiBhbmQgdGhlIGFjdG9yX3Rva2VuIGluIGNvbWJpbmF0aW9uIGFuZCBub3QgYXMgYSBj b21wb3NpdGUgb2Ygb25seSB0aGUgY2xhaW1zLiINClRoZSB3YW50X2NvbXBvc2l0ZSBwYXJhbWV0 ZXIgY2FtZSBhYm91dCBkdXJpbmcgc29tZSBpdGVyYXRpdmUgd29yayBvbiB0aGUgZG9jdW1lbnQg KGJldHdlZW4gSS1EIHB1YmxpY2F0aW9ucykgbGFzdCB5ZWFyLiBBdCBmaXJzdCB0aGUgY2xpZW50 IGNvdWxkIGV4cHJlc3MgdGhhdCBpdCB3YW50ZWQgYSBjb21wb3NpdGUgdG9rZW4sIG9uZSBjb250 YWluaW5nIGRlbGVnYXRpb24gc2VtYW50aWNzLCB3aXRoIHRoZSBpbmNsdXNpb24gb2YgdGhlIGFj dG9yX3Rva2VuIHBhcmFtZXRlci4gT25lIG9mIHRoZSBvdGhlciBlZGl0b3JzIHN1Z2dlc3RlZCwg aG93ZXZlciwgdGhhdCB0aGUgYWN0b3JfdG9rZW4gdG9rZW4gbWlnaHQgYmUgbmVjZXNzYXJ5IGZv ciBhdXRob3JpemF0aW9uIGluIGNhc2VzIGV2ZW4gd2hlbiB0aGUgY2xpZW50IHdhc24ndCBhc2tp bmcgZm9yIGEgY29tcG9zaXRlIHRva2VuIGFuZCB0aGF0IHBsYWNpbmcgdGhlIGRlc2lyZSBmb3Ig ZGVsZWdhdGlvbiBzZW1hbnRpY3Mgb24gaXQgd2FzIG92ZXJsb2FkaW5nIHRoZSBwYXJhbWV0ZXIg dG9vIG11Y2guIEkgaW50cm9kdWNlZCB0aGUgd2FudF9jb21wb3NpdGUgcGFyYW1ldGVyIHRvIGdp dmUgdGhlIGNsaWVudCBzdWNoIGEgc2lnbmFsIGluZGVwZW5kZW50IG9mIHRoZSBhY3Rvcl90b2tl biBwYXJhbWV0ZXIuIE15IChhZG1pdHRlZGx5IGluY29tcGxldGUpIHVuZGVyc3RhbmRpbmcgb2Yg V1MtVHJ1c3QgaXMgdGhhdCB0aGUgY2xpZW50L3JlcXVlc3RlciBjYW4gbWFrZSBzdWNoIGFuIGlu ZGljYXRpb24gYW5kIEkgd2FzIHRyeWluZyB0byBmb2xsb3cgdGhhdCBtb2RlbC4gSG93ZXZlciwg SSdtIG5vdCBzdXJlIGl0J3MgbmVlZGVkIG9yIGV2ZW4gbWFrZXMgbXVjaCBtdWNoIHNlbnNlLiBV bHRpbWF0ZWx5IGl0J3MgdGhlIHNlcnZlcidzIGRlY2lzaW9uIGFib3V0IGhvdyB0byBjb25zdHJ1 Y3QgdGhlIGlzc3VlZCB0b2tlbiBhbmQgd2hhdCB0byBpbmNsdWRlIGluIGl0LiBJdCBpcyB0aGUg c2VydmVyJ3MgcG9saWN5LCBub3QgYSBjbGllbnQgc2lnbmFsLCB3aGljaCBtYWtlcyB0aGUgZGV0 ZXJtaW5hdGlvbi4gU28gdGhlIHdhbnRfY29tcG9zaXRlIHBhcmFtZXRlciBpcyByZWFsbHkganVz dCBub2lzZSB0aGF0IG1ha2VzIHRoZSBzcGVjIGxvbmdlci4gQW5kLCBmcm9tIHRoZSBxdW90ZSBh Ym92ZSwgc2VlbXMgbWlnaHQgYWxzbyBsZWFkIHNvbWUgcmVhZGVycyB0byBpbmNvcnJlY3QgY29u Y2x1c2lvbnMgYWJvdXQgd2hhdCBjYW4gYW5kIGNhbm5vdCBiZSByZXR1cm5lZCBpbiBhIHRva2Vu IGV4Y2hhbmdlLg0KSSdkIHByb3Bvc2UgdGhlbiB0aGF0IHRoZSB3YW50X2NvbXBvc2l0ZSBwYXJh bWV0ZXIgYmUgZHJvcHBlZCBmcm9tIHRoZSBkb2N1bWVudC4NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_SN1PR0301MB2029A0BBD8C0E7AB3DB01A45A6FB0SN1PR0301MB2029_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VGhpbmdzIGhhdmUgZ290dGVuIHNvIG11ZGRsZWQgbm90IHN1cmUgd2hlcmUgdG8gYmVn aW4sIHRoZSBvcmlnaW5hbCBnb2FsIG9mIHRoaXMgZHJhZnQgd2FzIHRvIHByb3ZpZGUgdGhlIGZ1 bmN0aW9uIHRoYXQgd2UgdXNlIGluIGRhaWx5IGhpZ2ggdm9sdW1lIHByb2R1Y3Rpb24gb2YgV1Mt VHJ1c3QgYXMNCiB3ZSB0cmFuc2l0aW9uIHRvIE9hdXRoLiAmbmJzcDtXUy1UcnVzdCBwcm92aWRl ZCBtYW55IG9wdGlvbnMsIG9uZSB3YXMgQWN0QXMgYW5kIHRoZSBvdGhlciB3YXMgT25CZWhhbGZP ZiwgdGhlc2Ugd2VyZSAyIGRpc3RpbmN0IGZ1bmN0aW9ucyBidXQgY291bGQgYmUgY29tYmluZWQg KGFuZCB0aHVzIHRoZSByZXN1bHRzIGFyZSBvZiBhIGNvbXBvc2l0ZSBuYXR1cmUpLiBUaGVyZSB3 ZXJlIGFsc28gb3RoZXIgb3B0aW9ucyBsaWtlIGRlbGVnYXRlVG8sIEZvcndhcmRhYmxlDQogYW5k IERlbGVnYXRhYmxlLiBTbyB3ZSBoYXZlIHVzZSBjYXNlcyBmb3IgYWxsIHRoZXNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5TbyB3ZSBoYXZlIHN0cmFpZ2h0IGZvcndhcmQgc2NlbmFyaW9zIGZvciAoMSkgYSB0 b2tlbiByZXF1ZXN0IHRvIGJlIG9uIGJlaGFsZiBvZiBhIGdpdmVuL3NwZWNpZmllZCB0b2tlbiwg d2UgYWxzbyBoYXZlIGEgc3RyYWlnaHQgZm9yd2FyZCBzY2VuYXJpbyBmb3IgKDIpIHJlcXVlc3Rp bmcgYSB0b2tlbg0KIGJhc2VkIHVwb24gYSBzcGVjaWZpYyB0b2tlbi4gV2UgYWxzbyBoYXZlIGNv bXBsZXggc2NlbmFyaW9zIGZvciBjb21iaW5pbmcgdGhlIHNlbWFudGljcyBvZiBib3RoICZuYnNw OygxKSBhbmQgKDIpIHdoZXJlIHRoZSB0b2tlbiByZXF1ZXN0IGlzIG9uIGJlaGFsZiBvZiBhIHNw ZWNpZmljIHRva2VuIGFuZCB0aGUgcmVxdWVzdCBpcyBiYXNlZCB1cG9uIGEgc3BlY2lmaWMgdG9r ZW4sIHRoaXMgaGFwcGVuZWQgYSBsb3QgaW4gb3VyIHNlcnZlciB0byBzZXJ2ZXINCiBzY2VuYXJp b3MgZm9yIGFjY2VzcyB0byBiYWNrZW5kIGRvY3VtZW50cyBhbmQgc2VydmljZXMuIFdoZXJlIHdl IGhhdmUgY2hhaW5lZCBzZXJ2aWNlcyB0aGlzIGlzIHdoZXJlIHRoZSBkZWxlZ2F0ZVRvLCBGb3J3 YXJkYWJsZSBhbmQgRGVsZWdhdGFibGUgb3B0aW9ucyBjb21lIGludG8gdGhlIHNjZW5hcmlvLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5UaGUgd2F5IHRoYXQgdGhpcyBjdXJyZW50IHNwZWNpZmljYXRpb24gaXMg c3RydWN0dXJlZCBhbmQgd3JpdHRlbiB0aGUgU3ViamVjdCBpcyBhbHdheXMgcmVxdWlyZWQgd2hp Y2ggaXMgYSBub3QgYSBnb29kIHRoaW5nIHNpbmNlIHRoZXJlIG1heSBub3QgYmUgYSBzdWJqZWN0 LCBhcyBiYXNpYyB0b2tlbg0KIHJlcXVlc3RzIGRvbuKAmXQgaGF2ZSB0byBoYXZlIHN1YmplY3Rz IChqdXN0IGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzKSwgdGh1cyB5b3UgY2Fu4oCZdCBnZXQg dGhlIHNlbWFudGljcyBvZiAoMikgd2l0aG91dCAoMSkuIE5vdyB0aGUgc2VtYW50aWNzIG9mIGNv bWJpbmcgKDEpIGFuZCAoMikgc2VlbSB0byBiZSBub3QgdW5kZXJzdG9vZCBhbmQgd2FudGluZyB0 byBiZSByZW1vdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFJpY2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBT YXR1cmRheSwgQXVndXN0IDI3LCAyMDE2IDM6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENh bXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ ICZsdDtvYXV0aEBpZXRmLm9yZyZndDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBGb2xsb3dpbmcgdXAgb24gdG9rZW4gZXhjaGFuZ2Ug dXNlIGNhc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O byBvYmplY3Rpb25zLiBTaW1wbGlmaWNhdGlvbiBpcyBiZXR0ZXIsIGFuZCB0aGlzIHNwZWMgaXMg YWxyZWFkeSBmYWlybHkgY29udm9sdXRlZCB3aXRoIGFsbCB0aGUgb3B0aW9ucyB0dXJuZWQgb24u PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQg SnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBBdWcgMjYsIDIwMTYsIGF0IDE6MzAgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBo cmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ TG9va2luZyBmb3IgdHdvIHRoaW5ncyBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjEpIEFueSBvYmpl Y3Rpb25zIHRvIHJlbW92aW5nIHRoZSB3YW50X2NvbXBvc2l0ZSByZXF1ZXN0IHBhcmFtZXRlcj8g UGxlYXNlIGV4cGxhaW4sIGlmIHNvLiBJIHBsYW4gdG8gcmVtb3ZlIGl0IGluIHRoZSBuZXh0IGRy YWZ0IGJhcnJpbmcgYW4gb3V0cG91cmluZyBvZiBzdXBwb3J0IHRvIGtlZXAgaXQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpIFRvbnkgdG8gZXhwbGFpbiBo aXMgdXNlIGNhc2UgYW5kIGRlc2NyaWJlIHdoYXQgY2hhbmdlcyB3b3VsZCBiZSBuZWVkZWQgdG8g YWNjb21tb2RhdGUgaXQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgQXVnIDEsIDIwMTYgYXQgMjowMCBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0 OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkR1cmluZyB0aGUgbWVldGluZyBpbiBCZXJsaW4gVG9u eSB2b2ljZWQgY29uY2VybiBhYm91dCBhIHVzZSBjYXNlIGhlIGhhZCBmb3IgdG9rZW4gZXhjaGFu Z2UuIEhvbmVzdGx5LCBpdCdzIHN0aWxsIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSB3aGF0IHRo YXQgdXNlIGNhc2UgaXMgb3Igd2hhdCB3b3VsZCBuZWVkIHRvIGNoYW5nZSBpbiBzdXBwb3J0IG9m IGl0Lg0KIEknZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSBhbmQgc2Vl IGlmIGl0J3Mgc29tZXRoaW5nIHRoYXQgY2FuIHJlYXNvbmFibHkgYmUgYWNjb21tb2RhdGVkIHdp dGggVG9rZW4gRXhjaGFuZ2UuIER1cmluZyB0aGUgbWVldGluZyBUb255IHJlZmVycmVkIGJhY2sg dG8gYW4gZWFybGllciBlbWFpbCB3aGVyZSBoZSBzYWlkLCAmcXVvdDt3YW50X2NvbXBvc2l0ZSBp cyBub3QgcmVhbGx5IHRoZSBlZmZlY3Qgd2UgYXJlIGxvb2tpbmcgZm9yDQogc2luY2UgaXQgcHJv dmlkZXMgZm9yIGEgc2luZ2xlIHRva2VuLCB0aGUgdXNlIGNhc2Ugd2UgaGF2ZSBpcyB3aGVyZSB5 b3Ugd2FudCB0aGUgYWJpbGl0eSB0byB1c2UgdGhlIHN1YmplY3RfdG9rZW4gYW5kIHRoZSBhY3Rv cl90b2tlbiBpbiBjb21iaW5hdGlvbiBhbmQgbm90IGFzIGEgY29tcG9zaXRlIG9mIG9ubHkgdGhl IGNsYWltcy4mcXVvdDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGUgd2FudF9jb21wb3Np dGUgcGFyYW1ldGVyIGNhbWUgYWJvdXQgZHVyaW5nIHNvbWUgaXRlcmF0aXZlIHdvcmsgb24gdGhl IGRvY3VtZW50IChiZXR3ZWVuIEktRCBwdWJsaWNhdGlvbnMpIGxhc3QgeWVhci4gQXQgZmlyc3Qg dGhlIGNsaWVudCBjb3VsZCBleHByZXNzIHRoYXQgaXQgd2FudGVkIGEgY29tcG9zaXRlIHRva2Vu LCBvbmUgY29udGFpbmluZyBkZWxlZ2F0aW9uDQogc2VtYW50aWNzLCB3aXRoIHRoZSBpbmNsdXNp b24gb2YgdGhlIGFjdG9yX3Rva2VuIHBhcmFtZXRlci4gT25lIG9mIHRoZSBvdGhlciBlZGl0b3Jz IHN1Z2dlc3RlZCwgaG93ZXZlciwgdGhhdCB0aGUgYWN0b3JfdG9rZW4gdG9rZW4gbWlnaHQgYmUg bmVjZXNzYXJ5IGZvciBhdXRob3JpemF0aW9uIGluIGNhc2VzIGV2ZW4gd2hlbiB0aGUgY2xpZW50 IHdhc24ndCBhc2tpbmcgZm9yIGEgY29tcG9zaXRlIHRva2VuIGFuZCB0aGF0IHBsYWNpbmcgdGhl DQogZGVzaXJlIGZvciBkZWxlZ2F0aW9uIHNlbWFudGljcyBvbiBpdCB3YXMgb3ZlcmxvYWRpbmcg dGhlIHBhcmFtZXRlciB0b28gbXVjaC4gSSBpbnRyb2R1Y2VkIHRoZSB3YW50X2NvbXBvc2l0ZSBw YXJhbWV0ZXIgdG8gZ2l2ZSB0aGUgY2xpZW50IHN1Y2ggYSBzaWduYWwgaW5kZXBlbmRlbnQgb2Yg dGhlIGFjdG9yX3Rva2VuIHBhcmFtZXRlci4gTXkgKGFkbWl0dGVkbHkgaW5jb21wbGV0ZSkgdW5k ZXJzdGFuZGluZyBvZiBXUy1UcnVzdCBpcyB0aGF0DQogdGhlIGNsaWVudC9yZXF1ZXN0ZXIgY2Fu IG1ha2Ugc3VjaCBhbiBpbmRpY2F0aW9uIGFuZCBJIHdhcyB0cnlpbmcgdG8gZm9sbG93IHRoYXQg bW9kZWwuIEhvd2V2ZXIsIEknbSBub3Qgc3VyZSBpdCdzIG5lZWRlZCBvciBldmVuIG1ha2VzIG11 Y2ggbXVjaCBzZW5zZS4gVWx0aW1hdGVseSBpdCdzIHRoZSBzZXJ2ZXIncyBkZWNpc2lvbiBhYm91 dCBob3cgdG8gY29uc3RydWN0IHRoZSBpc3N1ZWQgdG9rZW4gYW5kIHdoYXQgdG8gaW5jbHVkZSBp biBpdC4NCiBJdCBpcyB0aGUgc2VydmVyJ3MgcG9saWN5LCBub3QgYSBjbGllbnQgc2lnbmFsLCB3 aGljaCBtYWtlcyB0aGUgZGV0ZXJtaW5hdGlvbi4gU28gdGhlIHdhbnRfY29tcG9zaXRlIHBhcmFt ZXRlciBpcyByZWFsbHkganVzdCBub2lzZSB0aGF0IG1ha2VzIHRoZSBzcGVjIGxvbmdlci4gQW5k LCBmcm9tIHRoZSBxdW90ZSBhYm92ZSwgc2VlbXMgbWlnaHQgYWxzbyBsZWFkIHNvbWUgcmVhZGVy cyB0byBpbmNvcnJlY3QgY29uY2x1c2lvbnMgYWJvdXQgd2hhdA0KIGNhbiBhbmQgY2Fubm90IGJl IHJldHVybmVkIGluIGEgdG9rZW4gZXhjaGFuZ2UuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdkIHByb3Bvc2UgdGhlbiB0aGF0IHRoZSB3YW50 X2NvbXBvc2l0ZSBwYXJhbWV0ZXIgYmUgZHJvcHBlZCBmcm9tIHRoZSBkb2N1bWVudC4mbmJzcDsN CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB2029A0BBD8C0E7AB3DB01A45A6FB0SN1PR0301MB2029_-- From nobody Thu Sep 8 17:54:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CA412B2F2 for ; Thu, 8 Sep 2016 17:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.227 X-Spam-Level: X-Spam-Status: No, score=-4.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzLefX4dmuCf for ; Thu, 8 Sep 2016 17:54:11 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (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 B627C12B1BC for ; Thu, 8 Sep 2016 17:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1473382449; bh=mWwE18qs4MmBmLS3qbYxpCf+WnnA0D+tbcItE+hwHo0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Bsc3o2Y8ugl5+stQLzwj6BVHy5MUKzCUqsFrApgQ3PrPYgSzPEHjCjHGEA3q8SBl6EweFF+CQf8D5wfXGlnK5jTeK3FqjhmAhDfwXcvJ9y65qOFEWgpqp3keX7av90EJ6sWC46A1Yvd7LYiPTZ4iF+QXp93DD5v3tQDtROAsCDbRQLf1XTJ7V9InZiACtfGtfkUqVgpZnjE3KQU3kIxHmulTIOIq7i5tcWRWelEH6aZhI1Bgb6+uyLKi92nYGnSfLmMTXXGURGprIT9bysEK5VDzb/TetyEPpR2aD7aIiqDXDMs52ub60KM24fNXrYdvgCTNMS2ntioUkiJzUJEwsg== Received: from [66.196.81.173] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 09 Sep 2016 00:54:09 -0000 Received: from [98.139.212.218] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 09 Sep 2016 00:54:09 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 09 Sep 2016 00:54:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 753974.9648.bm@omp1027.mail.bf1.yahoo.com X-YMail-OSG: q_Wh6U8VM1mhngxFc31IsbcHrxrMW0uHWU5LUNQzbqnBwf222hIMi466kCZclXn ciAXX6UTAr.c9mLgP1Klx.zF6sTQy_MopdiDNpWNtMVbh5gkRNc.MpZ6J5c0vhDXw1hpZ_EiRnz4 7ShMQS5m36LqAHKK8A9eKbyYXpyV66.6tKWF3hE_nYAp.dxNgUiDvtUr404H1AvKazu4XzPJ2LQx wOsixkJKD.U5kcqdXOzX_pyA8yYu2VctdzYR_k49XHmneb75pBX53uFqSpCX.JhTVmaS3QxEleap G3dIwGkoeAR3Dl8JiNCbK2tDc.DEKuyk39Q_I3vQoGaX0YjITBki6.TCRG8ENX9PKrrrDy3mfHpQ a.Zu06cnCRljv.esDBB9mOp2TC1HkTmmA4EFaLLgmAACYBxJPa2x9frj4xwBm5b1bVT92.46lRx6 iJ9v.i9cEbMtfWsgdPK52ctn5plsr3GKxXGilZj_jWTV55eciFaCqwJ5N6CaZbjty8PZkLxm0z1E 5LSvH6DGGD3LzVw_OeqrcT8GoGrr660NZgyBC Received: from jws106189.mail.bf1.yahoo.com by sendmailws146.mail.bf1.yahoo.com; Fri, 09 Sep 2016 00:54:09 +0000; 1473382449.356 Date: Fri, 9 Sep 2016 00:54:08 +0000 (UTC) From: Oleg Gryb To: Jim Manico , John Bradley Message-ID: <951244384.2140569.1473382448817@mail.yahoo.com> In-Reply-To: <3be430fb-afe7-ab94-1369-7fcdfdedec0b@manicode.com> References: <632483756.1929562.1473358500330@mail.yahoo.com> <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com> <1013244548.1998164.1473366003274@mail.yahoo.com> <9265cef3-7859-cb09-ffe1-5d73a72af03e@manicode.com> <3be430fb-afe7-ab94-1369-7fcdfdedec0b@manicode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2140568_1188358003.1473382448798" Archived-At: Cc: Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 00:54:12 -0000 ------=_Part_2140568_1188358003.1473382448798 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "keep away from implicit grants and do not store bearer tokens in the brows= er" - that would be practically impossible for the envs that I was writing = about and "best practices"=C2=A0 that could not be enforced aren't worth mu= ch. I can formulate it in stronger terms: if OAuth wouldn't allow a JS clie= nt running in a browser its usability will be very low. What could and should be improved in implicit grants is removing secrets fr= om URL (fragment). That could be done as I've shown in the previous discuss= ions. =20 From: Jim Manico To: John Bradley =20 Cc: Oleg Gryb ; Adam Lewis ; OAuth WG Sent: Thursday, September 8, 2016 3:51 PM Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage =20 +1000 on a OAuth Security Best Practices document. I'd be happy to review = or help some.=20 I think right now the answer is: keep away from implicit grants and do no= t store bearer tokens in the browser. Instead, use the authorization code g= rant which only exposes bearer tokens intra-server. For web apps, I feel th= e only good place to store authentication, session or token information is = in a HTTPOnly flagged cookie to keep JS away from sensitive information. =20 Aloha, Jim =20 =20 On 9/8/16 12:38 PM, John Bradley wrote: =20 =20 It is an interesting discussion, indicating that perhaps a best practices = document is in order.=20 I have had several people ask me about SPA using OAuth recently.=20 Until we get the W3C to finish fetch and extend it for token binding, we = are going to have ongoing issues with bearer tokens in the browser and wher= e to store them.=20 I don=E2=80=99t know that there is a perfect solution for bearer tokens, = but documenting the tradeoffs may be useful.=20 John B.=20 =20 On Sep 8, 2016, at 6:07 PM, Jim Manico wrote:=20 =20 +1 I think that's a very fair perspective. Putting sensitive data in Local= Storage is still a very bad idea. :) One XSS and gone. Maybe XSS is not a b= ig deal in a native app, but it's death to Web apps. Aloha, Jim =20 On 9/8/16 10:20 AM, Oleg Gryb wrote: =20 In SPA/REST env session ID is not very useful, so it's *an* auth token or = tokens (not necessary OAuth one) that are stored in a cookie. It's used to = get REST calls authenticated and yes, it usually runs in a multi-domain env= s (think about micro services architecture). It makes me think that the val= ue of HTTPOnly will continue diminishing, while the value of good cross-dom= ain policies will increase. Just my opinion coming from my experience. I do= n't have big (or small) data available to confirm that. =C2=A0=20 =20 =20 =20 From: Jim Manico To: Oleg Gryb ; Adam Lewis =20 Cc: OAuth WG Sent: Thursday, September 8, 2016 12:51 PM Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage =20 > Since SPA is a new normal now, it becomes extremely difficult to enfor= ce HTTPOnly flag, because JS needs access to secrets including those stored= in cookies. In a browser environment, this is only true when you need to m= ake cross domain requests or are using cookie data for something other than= session state. If your current page origin and the page you are requesting= are the same, then your cookies can be HTTPOnly without impacting function= ality. If you need additional cookies for other things that need to be acc= essed via JS, use a separate cookie. So sure, there are a few workflows in = OAuth where you need to access "cookie data" from JS and HTTPOnly is not vi= able. But there are a few where it is viable. I don't think it's as simple = as "we need to talk to cookie data via JS all the time.". Aloha, Jim On 9/8/16 8:15 AM, Oleg Gryb wrote: =20 Jim,=20 It's outdated a bit. Since SPA is a new normal now, it becomes extremely = difficult to enforce HTTPOnly flag, because JS needs access to secrets incl= uding those stored in cookies. 5-10 years ago I would always enforce HTTPO= nly and now - I can't.=20 Thanks, Oleg. =20 From: Jim Manico To: Adam Lewis =20 Cc: OAuth WG Sent: Thursday, September 8, 2016 10:45 AM Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage =20 In the web world, cookies for session identifiers are much safer - sinc= e we can use HTTPOnly cookies to protect them from theft via XSS. The same = mechanism is not possible for localStorage. Overall, security folk say =E2= =80=A2keep sensitive data out of localStorage=E2=80=A2 since one XSS and i= t's stolen. There is also a huge body of work underway to make secure cook= ies even more so.=20 I'm not sure how this translates to native apps. =20 -- Jim Manico @Manicode =20 On Sep 8, 2016, at 3:02 AM, Adam Lewis = wrote: =20 =20 Hi,=20 The WG is currently putting together best practices for native apps.=C2= =A0 I would like to better understand the best practices around ua-based-a= pps, especially as it relates totoken=C2=A0storage.=C2=A0 I've read various= blog posts about the preference between storing tokens in cookies vs.=C2= =A0=C2=A0Web Storage (localStorage/sessionStorage).=C2=A0 The current set o= f specs are rather silent on the matter, as it is more of an implementatio= n issue (but that is where most mistakes are made).=20 What is the WG's guidance on this? =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 --=20 Jim Manico Manicode Security https://www.manicode.com =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 --=20 Jim Manico Manicode Security https://www.manicode.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 Jim Manico Manicode Security https://www.manicode.com=20 =20 =20 ------=_Part_2140568_1188358003.1473382448798 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable = ------=_Part_2140568_1188358003.1473382448798-- From nobody Thu Sep 8 17:58:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03ED12B313 for ; Thu, 8 Sep 2016 17:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQXd58lVQ0Z9 for ; Thu, 8 Sep 2016 17:58:06 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7110A12B312 for ; Thu, 8 Sep 2016 17:58:06 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id to9so22440503pac.1 for ; Thu, 08 Sep 2016 17:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=GoJCuI0+Pir2kO+Fc4RwFuWDUKbyGmHSMjtrTlXkpWg=; b=Ckv6dVYCeo7vDDwSvVKKoI38Ao1PM111E4cfApp20TykspEY1WN1k1eiSTOVMByGpG Vv5TaGdL5Fsl5x5k9nG3bO99maMzjNsHsDIDQ0sHuSEocNmg/ovOThHAb8olQtB3aTNP EGow33IFi07qW/yN0djJJYGOtkB2seq1P9gRsSgtYWslTYiRmlXe34ftsEO2AKA913UK EQrkXWUD40PADeSMmomwh9RKTt3wYu/q+RDn9N8eRW96zth5zexDVedeioh2rofbz0eO KKU4dwgsowT6rbT5dYdE5vYPJnnsjDoMN9XoUI3eJy+HOBp9CpAqpCcogBEKmmBQtYCN eQPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=GoJCuI0+Pir2kO+Fc4RwFuWDUKbyGmHSMjtrTlXkpWg=; b=O1C8PkK6V4s3lPJCZfOlkv+K+bksYd/HFuD0P4HyR0GVPKNGB0qNmqeiPe1okYFvFE BlVJB41AJFi1J/ZqdI6PG7n4I/DgAHVLHVOFdOfhiXmV//KJUEyk9Rh4ltDlX5lKydlf vIPw/LNUHXMnPZkIXonCaKrd/8rIvN97+UY+Ysxpw+0dEIYFHXCYa5e2tOH24GoQd1Zn JKgNaHAj4PkR5cRF1mBFKRVAj3+HKq/+zvMFZnusUcdzjXVRQZv4E6YJB7H5fXirnJnu oNmrb9YjUEPB1Fkz0+l1oHcX+7br887Dh00gT/GlwpOv+zJsWAugq+IPFoQsF/I0bjgR xsWg== X-Gm-Message-State: AE9vXwOVD2BUXUSPPM8pwJnP07vQTfZIfn+6gcEdKq+CjknXdMcwPTk0ps5FeydNA8SPvFte X-Received: by 10.66.85.196 with SMTP id j4mr1615570paz.40.1473382685779; Thu, 08 Sep 2016 17:58:05 -0700 (PDT) Received: from heembo.local ([2605:e000:112b:c167:3ccb:e369:74b0:50fc]) by smtp.googlemail.com with ESMTPSA id f62sm491111pfj.75.2016.09.08.17.58.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 17:58:03 -0700 (PDT) To: Oleg Gryb , John Bradley References: <632483756.1929562.1473358500330@mail.yahoo.com> <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com> <1013244548.1998164.1473366003274@mail.yahoo.com> <9265cef3-7859-cb09-ffe1-5d73a72af03e@manicode.com> <3be430fb-afe7-ab94-1369-7fcdfdedec0b@manicode.com> <951244384.2140569.1473382448817@mail.yahoo.com> From: Jim Manico Message-ID: <8dceec1a-8f32-7ab3-449f-0d2e5f303258@manicode.com> Date: Thu, 8 Sep 2016 14:58:01 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <951244384.2140569.1473382448817@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------6896E3AD1FDC0DE7F1AED19F" Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 00:58:08 -0000 This is a multi-part message in MIME format. --------------6896E3AD1FDC0DE7F1AED19F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit > "keep away from implicit grants and do not store bearer tokens in the browser" - that would be practically impossible for the envs that I was writing about and "best practices" that could not be enforced aren't worth much. I can formulate it in stronger terms: if OAuth wouldn't allow a JS client running in a browser its usability will be very low. Are you sure you're not talking about OIDC or JWT's? The piece of advice above is regarding using OAuth for delegation per the core spec. Advice for Federation (OIDC) and advice for session management (putting JTW's in cookies) would be different that recommending how to use OAuth for delegation securely. Fair? - Jim On 9/8/16 2:54 PM, Oleg Gryb wrote: > "keep away from implicit grants and do not store bearer tokens in the > browser" - that would be practically impossible for the envs that I > was writing about and "best practices" that could not be enforced > aren't worth much. I can formulate it in stronger terms: if OAuth > wouldn't allow a JS client running in a browser its usability will be > very low. > > What could and should be improved in implicit grants is removing > secrets from URL (fragment). That could be done as I've shown in the > previous discussions. > > > ------------------------------------------------------------------------ > *From:* Jim Manico > *To:* John Bradley > *Cc:* Oleg Gryb ; Adam Lewis > ; OAuth WG > *Sent:* Thursday, September 8, 2016 3:51 PM > *Subject:* Re: [OAUTH-WG] best practices for implicit grant / > token storage > > +1000 on a OAuth Security Best Practices document. I'd be happy to > review or help some. > I think right now the answer is: keep away from implicit grants > and do not store bearer tokens in the browser. Instead, use the > authorization code grant which only exposes bearer tokens > intra-server. > For /*web apps*/, I feel the only good place to store > authentication, session or token information is in a HTTPOnly > flagged cookie to keep JS away from sensitive information. > > Aloha, Jim > > > On 9/8/16 12:38 PM, John Bradley wrote: > It is an interesting discussion, indicating that perhaps a best > practices document is in order. > > I have had several people ask me about SPA using OAuth recently. > > Until we get the W3C to finish fetch and extend it for token > binding, we are going to have ongoing issues with bearer tokens in > the browser and where to store them. > > I don’t know that there is a perfect solution for bearer tokens, > but documenting the tradeoffs may be useful. > > John B. > >> On Sep 8, 2016, at 6:07 PM, Jim Manico > > wrote: >> > +1 I think that's a very fair perspective. > Putting sensitive data in LocalStorage is still a very bad idea. > :) One XSS and gone. Maybe XSS is not a big deal in a native app, > but it's death to Web apps. > Aloha, Jim > > On 9/8/16 10:20 AM, Oleg Gryb wrote: >> In SPA/REST env session ID is not very useful, so it's *an* auth >> token or tokens (not necessary OAuth one) that are stored in a >> cookie. It's used to get REST calls authenticated and yes, it >> usually runs in a multi-domain envs (think about micro services >> architecture). It makes me think that the value of HTTPOnly will >> continue diminishing, while the value of good cross-domain >> policies will increase. Just my opinion coming from my >> experience. I don't have big (or small) data available to confirm >> that. >> >> >> ------------------------------------------------------------------------ >> *From:* Jim Manico >> *To:* Oleg Gryb ; >> Adam Lewis >> >> *Cc:* OAuth WG >> *Sent:* Thursday, September 8, 2016 12:51 PM >> *Subject:* Re: [OAUTH-WG] best practices for implicit grant / >> token storage >> >> > Since SPA is a new normal now, it becomes extremely >> difficult to enforce HTTPOnly flag, because JS needs access >> to secrets including those stored in cookies. >> In a browser environment, this is only true when you need to >> make cross domain requests or are using cookie data for >> something other than session state. >> If your current page origin and the page you are requesting >> are the same, then your cookies can be HTTPOnly without >> impacting functionality. If you need additional cookies for >> other things that need to be accessed via JS, use a separate >> cookie. >> So sure, there are a few workflows in OAuth where you need to >> access "cookie data" from JS and HTTPOnly is not viable. But >> there are a few where it is viable. I don't think it's as >> simple as "we need to talk to cookie data via JS all the time.". >> Aloha, Jim >> On 9/8/16 8:15 AM, Oleg Gryb wrote: >>> Jim, >>> >>> It's outdated a bit. Since SPA is a new normal now, it >>> becomes extremely difficult to enforce HTTPOnly flag, >>> because JS needs access to secrets including those stored in >>> cookies. 5-10 years ago I would always enforce HTTPOnly and >>> now - I can't. >>> >>> Thanks, >>> Oleg. >>> >>> ------------------------------------------------------------------------ >>> *From:* Jim Manico >>> >>> *To:* Adam Lewis >>> >>> *Cc:* OAuth WG >>> *Sent:* Thursday, September 8, 2016 10:45 AM >>> *Subject:* Re: [OAUTH-WG] best practices for implicit >>> grant / token storage >>> >>> In the web world, cookies for session identifiers are >>> much safer - since we can use HTTPOnly cookies to >>> protect them from theft via XSS. The same mechanism is >>> not possible for localStorage. Overall, security folk >>> say •keep sensitive data out of localStorage• since one >>> XSS and it's stolen. There is also a huge body of work >>> underway to make secure cookies even more so. >>> >>> I'm not sure how this translates to native apps. >>> >>> -- >>> Jim Manico >>> @Manicode >>> >>> On Sep 8, 2016, at 3:02 AM, Adam Lewis >>> >> > wrote: >>> >>>> Hi, >>>> >>>> The WG is currently putting together best practices for >>>> native apps. I would like to better understand the >>>> best practices around ua-based-apps, especially as it >>>> relates to token storage. I've read various blog posts >>>> about the preference between storing tokens in cookies >>>> vs. Web Storage (localStorage/sessionStorage). The >>>> current set of specs are rather silent on the matter, >>>> as it is more of an implementation issue (but that is >>>> where most mistakes are made). >>>> >>>> What is the WG's guidance on this? >>>> _______________________________________________ >>>> 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 >>> >>> >> >> -- >> Jim Manico >> Manicode Security >> https://www.manicode.com >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > -- > Jim Manico > Manicode Security > https://www.manicode.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > Jim Manico > Manicode Security > https://www.manicode.com > > > -- Jim Manico Manicode Security https://www.manicode.com --------------6896E3AD1FDC0DE7F1AED19F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

> "keep away from implicit grants and do not store bearer tokens in the browser" - that would be practically impossible for the envs that I was writing about and "best practices"  that could not be enforced aren't worth much. I can formulate it in stronger terms: if OAuth wouldn't allow a JS client running in a browser its usability will be very low.

Are you sure you're not talking about OIDC or JWT's? The piece of advice above is regarding using OAuth for delegation per the core spec. Advice for Federation (OIDC) and advice for session management (putting JTW's in cookies) would be different that recommending how to use OAuth for delegation securely.

Fair?

- Jim


On 9/8/16 2:54 PM, Oleg Gryb wrote:
"keep away from implicit grants and do not store bearer tokens in the browser" - that would be practically impossible for the envs that I was writing about and "best practices"  that could not be enforced aren't worth much. I can formulate it in stronger terms: if OAuth wouldn't allow a JS client running in a browser its usability will be very low.

What could and should be improved in implicit grants is removing secrets from URL (fragment). That could be done as I've shown in the previous discussions.


From: Jim Manico <jim@manicode.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Oleg Gryb <oleg@gryb.info>; Adam Lewis <adam.lewis@motorolasolutions.com>; OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 3:51 PM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

+1000 on a OAuth Security Best Practices document. I'd be happy to review or help some.
I think right now the answer is: keep away from implicit grants and do not store bearer tokens in the browser. Instead, use the authorization code grant which only exposes bearer tokens intra-server.
For web apps, I feel the only good place to store authentication, session or token information is in a HTTPOnly flagged cookie to keep JS away from sensitive information.

Aloha, Jim


On 9/8/16 12:38 PM, John Bradley wrote:
It is an interesting discussion, indicating that perhaps a best practices document is in order.

I have had several people ask me about SPA using OAuth recently.

Until we get the W3C to finish fetch and extend it for token binding, we are going to have ongoing issues with bearer tokens in the browser and where to store them.

I don’t know that there is a perfect solution for bearer tokens, but documenting the tradeoffs may be useful.

John B.

On Sep 8, 2016, at 6:07 PM, Jim Manico <jim@manicode.com> wrote:

+1 I think that's a very fair perspective.
Putting sensitive data in LocalStorage is still a very bad idea. :) One XSS and gone. Maybe XSS is not a big deal in a native app, but it's death to Web apps.
Aloha, Jim

On 9/8/16 10:20 AM, Oleg Gryb wrote:
In SPA/REST env session ID is not very useful, so it's *an* auth token or tokens (not necessary OAuth one) that are stored in a cookie. It's used to get REST calls authenticated and yes, it usually runs in a multi-domain envs (think about micro services architecture). It makes me think that the value of HTTPOnly will continue diminishing, while the value of good cross-domain policies will increase. Just my opinion coming from my experience. I don't have big (or small) data available to confirm that.  


From: Jim Manico <jim@manicode.com>
To: Oleg Gryb <oleg@gryb.info>; Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 12:51 PM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

> Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies.
In a browser environment, this is only true when you need to make cross domain requests or are using cookie data for something other than session state.
If your current page origin and the page you are requesting are the same, then your cookies can be HTTPOnly without impacting functionality. If you need additional cookies for other things that need to be accessed via JS, use a separate cookie.
So sure, there are a few workflows in OAuth where you need to access "cookie data" from JS and HTTPOnly is not viable. But there are a few where it is viable. I don't think it's as simple as "we need to talk to cookie data via JS all the time.".
Aloha, Jim
On 9/8/16 8:15 AM, Oleg Gryb wrote:
Jim,

It's outdated a bit. Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies. 5-10 years ago I would always enforce HTTPOnly and now - I can't.

Thanks,
Oleg.
From: Jim Manico <jim@manicode.com>
To: Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 10:45 AM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

In the web world, cookies for session identifiers are much safer - since we can use HTTPOnly cookies to protect them from theft via XSS. The same mechanism is not possible for localStorage. Overall, security folk say •keep sensitive data out of localStorage• since one XSS and it's stolen. There is also a huge body of work underway to make secure cookies even more so.

I'm not sure how this translates to native apps.

--
Jim Manico
@Manicode

On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Hi,

The WG is currently putting together best practices for native apps.  I would like to better understand the best practices around ua-based-apps, especially as it relates to token storage.  I've read various blog posts about the preference between storing tokens in cookies vs.  Web Storage (localStorage/sessionStorage).  The current set of specs are rather silent on the matter, as it is more of an implementation issue (but that is where most mistakes are made).

What is the WG's guidance on this?
_______________________________________________
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



-- 
Jim Manico
Manicode Security
https://www.manicode.com

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



-- 
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


-- 
Jim Manico
Manicode Security
https://www.manicode.com



-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------6896E3AD1FDC0DE7F1AED19F-- From nobody Thu Sep 8 23:32:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC9412B0F7 for ; Thu, 8 Sep 2016 23:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.109 X-Spam-Level: X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlKyjJc0BBLL for ; Thu, 8 Sep 2016 23:32:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610D412B0E6 for ; Thu, 8 Sep 2016 23:32:16 -0700 (PDT) Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LfC00-1bFoQ60FdA-00oooi; Fri, 09 Sep 2016 08:32:10 +0200 To: Mike Jones , "oauth@ietf.org" References: From: Hannes Tschofenig Message-ID: <608a9ce0-cdfc-62ec-2419-a3a66e412f66@gmx.net> Date: Fri, 9 Sep 2016 08:32:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sE+Hh/h4B9IPZ9inKBEFdtS0g0aqFNHeJ60q8UvCV0DOYQocus9 iZHjVEvQNL8vsXIf0B5tys7t4TAQ0YwVlXva1tPSTUpC2HVixNfO3UC5Lfh7FmkaiV8Z7qA VUTpnYtAC7tRx0AFJ2jZWqclavdQa32Z12aaAHtct74SMUG+DaGYcroLMeZR9/+Fl2ra07B mQ8kUJNAjKhpFJ/krW5ag== X-UI-Out-Filterresults: notjunk:1;V01:K0:dGAw4l1ZGj4=:UXnoUcmT8bnE792D3T/0uq yEXV6cZakhsie6dF/Un6FEbCdz9/Jq4dMUEMudon9/NBxSr028aLvXWS3ROJt6pgVemWNqpuh He2SInvS7p1enFkMfkzGXqi50qafRhAp4UVL6m2Vpv2poKnKLJD13CmWDSxN+h3aHkK89Z+Bt OQmd5nuKp8k8Qje8LgYx/y+FN27JN5H75nhgnDrJ4umy3JnRlHIj2dZ2Vt/p7ydwuAGxWbXDQ AnM248uLzkaVQfeTz9piHQWeHPvaz5mc3/YVwD0ZutkrcoObHV2HKQumPAi00AuO3X54w78Jf 0NG2aWAnr8NvQ07BdRojjGowp6jvsPRue3nROWbktfSNhu9IPOqhWSceFSaAQbRix9KbGi1Kc s5Uf9IwUAzaP4ZchYaAW8Iz9WP/6Vz/cwPgOsopmoCDEeEQuxXunDepijoXwonIZ2v3p3qPPv Iz2RCyFCJBP7qqwVVfiGfG+53GPBTfKteXNjp2HYkgt+3YQbz1R/EtxJiW4wul/Y1UoIVQtk6 ykNLD8urWIF1DQyCCiIphkX8trM0yWsB/ERSXqs7jVeBBuqwqOtv5d49DXxY5je3uPCPB9FCo 01iXrUG9J15FBGUHJVG6C3idpf8kTgeDpKiFJvQZUhaSwvaYeGWV4vi4tkObB2+H2rsMygO0U yisQXPzrewcEvKsRVLILvrlo2T1h2uRMy9uWFmOLv+2uW6WWoWNdViqkwtUlyVYtI7qBjo9Fh A6/+EDsNsWPGd/C1tJzgobyhHPucFE1VeUAF6o1DZ5vsamLreHkP2m/q/CtZRO5xrqzBmVWfT +L/+W94 Archived-At: Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-amr-values-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 06:32:19 -0000 Hi Mike, thanks for the response. I am fine with your explanations. Ciao Hannes On 09/03/2016 02:00 AM, Mike Jones wrote: > Thanks for your review, Hannes. Replies are inline... > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Wednesday, August 3, 2016 12:51 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Review of draft-ietf-oauth-amr-values-01 > > Hi Mike, Phil, Tony, > > I have read through draft-ietf-oauth-amr-values-01. My earlier comments have been addressed. > > As a shepherd I nevertheless have a few questions/remarks: > > 1) The term 'multiple-channel authentication' is unfamiliar to me. > Could you give me an example or a reference to a specification? > > https://www.ldapwiki.com/wiki/Multiple-channel%20Authentication has a clear explanation. However, I'm reluctant to reference a wiki page that may be transient from an RFC. If anyone out there has a more stable reference to suggest, please do so. Instead, I've added this example text for -02: > > For instance, a multiple-channel authentication might involve both entering information into > a workstation's browser and providing information on a telephone call to a pre-registered number. > > 2) PIN: The use of RFC 2119 language appears to be inappropriate. > > Thanks, will be fixed in -02. > > 3) Could you explain me what 'risk-based authentication' is? While you provided a reference > > https://en.wikipedia.org/wiki/Risk-based_authentication has a clear explanation. Bruce Schneier writes about it in a blog post here https://www.schneier.com/blog/archives/2013/11/risk-based_auth.html. Deloitte has a primer at http://deloitte.wsj.com/cio/2013/10/30/risk-based-authentication-a-primer/. There's lots of material on the web and the term is pretty widely known in authentication/identity circles. Unfortunately, as with "mca", I don't know of a great authoritative reference to cite. Any suggestions out there? > > 4) Could we generalize the term 'wia' to operating systems other than Windows as well? > > I don't think so. It consists of a particular set of documented protocol interactions, as describe at http://blogs.msdn.com/b/benjaminperkins/archive/2011/09/14/iis-integrated-windows-authentication-with-negotiate.aspx. That said, because these protocols are publicly documented, other systems (maybe SAMBA?) may have also implemented it. > > 5) I am not sure whether all normative references indeed need to be declared as such. > For example, 'otp' is defined in a very generic fashion but you list HTOP, and TOTP as normative references. > I would rather see HTOP and TOTP as a standardized examples of one-time-passwords. IMHO the story would be different if you indeed want to differentiate between the different technical mechanisms itself. This is a reasonable approach as well if the security differences between the mechanisms is important for the given application. > > If use cases arise in which applications want to define additional "amr" values "hotp" and/or "totp", they can use the registry established by this application to do so. It's explicitly not a goal of this specification to define all practical values. Rather, it defines a few values that are actually in production use and even more importantly, establishes the registry for defining more, as needed in practice. > > Ciao > Hannes > > > Thanks again, > -- Mike > > > From nobody Fri Sep 9 09:49:25 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1622C12B1E3; Fri, 9 Sep 2016 09:49:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147343976408.30839.3155170987767555925.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2016 09:49:24 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-amr-values-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 16:49:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : Authentication Method Reference Values Authors : Michael B. Jones Phil Hunt Anthony Nadalin Filename : draft-ietf-oauth-amr-values-02.txt Pages : 12 Date : 2016-09-09 Abstract: The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-amr-values-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 9 09:54:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A38012B1BE for ; Fri, 9 Sep 2016 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXPj_rmRZulw for ; Fri, 9 Sep 2016 09:54:36 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0113.outbound.protection.outlook.com [104.47.32.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FF712B0D0 for ; Fri, 9 Sep 2016 09:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N1v2RyIKtKHRZu4KaZcMwEUBIKdCiFxCrUXj7v3Qy4g=; b=MM2vpwxEqAGjmqObPSRaBRETRq5W+PGNC+IOQzzcVdReLr+SXvOr1ObGbYOHP19JaFkoyw/Hs1bLX+DQ4VS4AmW4LEwRPI5CAu1iyPpRRzJWXlkyznJ8fXu2bgD3emwUcLsUECspyParQTuWxxiMzzSG1xpo53iM66CTVRnv4SE= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Fri, 9 Sep 2016 16:54:35 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0599.016; Fri, 9 Sep 2016 16:54:35 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: =?Windows-1252?Q?=93amr=94_Values_specification_addressing_WGLC_comments?= Thread-Index: AdIKuBa5B4Bt83ZBS9ed7J1IGDDWTw== Date: Fri, 9 Sep 2016 16:54:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.134] x-ms-office365-filtering-correlation-id: 80c5742d-36e6-48c9-e538-08d3d8d1fa66 x-microsoft-exchange-diagnostics: 1; BN3PR03MB2355; 6:4dN+jC+pgdgE277BfAIkoKGE+CraNYXCNNwHmvnJYFtBGGzCwah5Dl+tyiKtRKYphrm5CLH+x4Kqdz07zvH6MifFOWGXAmdnPe0q54NZrfHT3ooh+SufpyEo6taMYtKsdsZNGvHKGKOcTwaXri5l1KKH3CVfyyqPKkdGOs6gQcKS9Mwd0Je2FyVCrZh7yl1yDVZK859zgUrAidnu61Oj4HMPrZJiae4x3G96vUnQ9JDYHVsaxVnJecZsaggq88rUkKihXygsO+l7lqKoVoy/ikHDnAZ3AfwYUYej7AOHPtuiZ1z6tI6/idAJqAO0/s2zBziGkf2xZBIkzDFNAuHh0Q==; 5:7atgAiimNqTuzoMYz1hCktkkPzxpNlTfNrLC7B72b2HJIwRVe2atX8mrqIHncI2DM73pBl4DFNMJ/hlujyd11NtKlmhRFiO0zVeQIgRZNZYfsHuhZ1EGkrOSM+8Vbb+OUttzvAVJh2LFV4VTeHIpyg==; 24:Gg0oekfJUrLvBg6PAfdaFJXeFfpwP8jeL0Vgn00XLWai1UfPVRR2/Kmw3FV1xSrGaVOY4DdFth6LyHpBstJIMY4MkzvfHzWGMuBcrEGH2fc=; 7:qyS/yycelwNzbjOg3/3bOEZaIXpelFuVpGw3uK+FQ1vivfwnPk76JOxFcFfAo+2e4stBLmuifU98MnqNP3XbDipaT27Wd22sSS1Sr5PvOQPvwvcK//zPpG/GHk0RTG5Vy1bCzvAIQmWtoPQOiPTOLRQxgYnrCUCEjnmAB9WbPaoBzhc+x3yuPANve+yGkC94AYxqeDHW/8KHBruOE/uQw8+rOXR6RuGeaoHvFx0tfqtGj2+YBz0O/rJGMCSTwweI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2355; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB2355; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2355; x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(189002)(11100500001)(3846002)(81166006)(3280700002)(2351001)(7736002)(87936001)(10400500002)(10090500001)(7906003)(19625215002)(97736004)(50986999)(790700001)(7846002)(5005710100001)(110136002)(5630700001)(2501003)(101416001)(74316002)(77096005)(107886002)(15975445007)(19580395003)(7696004)(9686002)(102836003)(450100001)(2900100001)(8936002)(2906002)(76576001)(10290500002)(99286002)(19617315012)(122556002)(105586002)(33656002)(5002640100001)(81156014)(86612001)(3660700001)(586003)(16236675004)(5660300001)(68736007)(19300405004)(6116002)(229853001)(86362001)(189998001)(66066001)(54356999)(5640700001)(8990500004)(92566002)(1730700003)(106356001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2355; H:BN3PR03MB2355.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB23554C1B8CF5EA0E33244E1EF5FA0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2016 16:54:34.8621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2355 Archived-At: Subject: [OAUTH-WG] =?windows-1252?q?=93amr=94_Values_specification_addres?= =?windows-1252?q?sing_WGLC_comments?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 16:54:39 -0000 --_000_BN3PR03MB23554C1B8CF5EA0E33244E1EF5FA0BN3PR03MB2355namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Draft -02 of the Authentication Method Reference Values specification addre= sses the Working Group Last Call (WGLC) comments received. It adds an exam= ple to the multiple-channel authentication description and moves the =93amr= =94 definition into the introduction. No normative changes were made. The specification is available at: =B7 http://tools.ietf.org/html/draft-ietf-oauth-amr-values-02 An HTML-formatted version is also available at: =B7 http://self-issued.info/docs/draft-ietf-oauth-amr-values-02.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1607 and as= @selfissued. --_000_BN3PR03MB23554C1B8CF5EA0E33244E1EF5FA0BN3PR03MB2355namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Draft -02 of the Authentication Method Reference Val= ues specification addresses the Working Group Last Call (WGLC) comments rec= eived.  It adds an example to the multiple-channel authentication desc= ription and moves the =93amr=94 definition into the introduction.  No normative changes were made.

 

The specification is available at:

=B7       http://tools.ietf.org/html/draft-ietf-oauth-amr-v= alues-02

 

An HTML-formatted version is also available at:=

=B7       http://self-issued.info/docs/draft-ietf-oa= uth-amr-values-02.html

 

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

 

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

--_000_BN3PR03MB23554C1B8CF5EA0E33244E1EF5FA0BN3PR03MB2355namp_-- From nobody Fri Sep 9 13:15:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E10712B351 for ; Fri, 9 Sep 2016 13:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O80M8p-ebdiZ for ; Fri, 9 Sep 2016 13:15:06 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E550412B027 for ; Fri, 9 Sep 2016 13:15:05 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id m11so162859735oif.1 for ; Fri, 09 Sep 2016 13:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vxUlux7cvgarppPFMBk09N085udwwl64zQ2DGvCG7jg=; b=efSHs03cDNm6sC519VCQtpWxfrvBRzQy3vYz1Ks9VS/ZrRTAIMR/83skF1H4OAYb05 RA98dFrw1KnpL99If1KBJgY8RrO2UV/zwJ9R0nPeTGQ7ZSzkiYchcZvXaeTkMv4rXQeT WzLpjnGKja5cskOKJvXUZxEXWYvKMLNWQmVJw= 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; bh=vxUlux7cvgarppPFMBk09N085udwwl64zQ2DGvCG7jg=; b=VTD+WWwrjf9xnK64zxcb53V1PHYjflE6B80aT+knwCWrLVumY8ZAYwUCel0mqWwrGa 5WOyMXWjDk+sz46nh/GaziRsouVnyb4QhipfU7aC2kl1yvwk8C329JAi6sDIMe4/Eadg kNkPsvBEj5EB5DdHjj40Z539RBSk6sdPStDk4PtE7yH3EvTVBpaoqfCdZCdl1XFR0rQT 1UMQ/kaxgTDQcntKSQ2v7YSt78aCcMXNO+C1FX27AGL/Ehv2IL5cp3K4dbkKqy7BbrEJ g6RP3ceCXk3+19j93Gq1Yo2//LAYfe7drHFUb8o3r/Fjw/DP0ETcYu7+GJ7iDu46VL3H KScQ== X-Gm-Message-State: AE9vXwOcf0vwCnC7LW8vdfI86GvjMxrHTp5w+7zPvZB1HrhK9sQ5Rkw4xk6+VrJGsYxb3d+V7DfIfM2J2hCmeYWK X-Received: by 10.157.21.88 with SMTP id z24mr6856913otz.33.1473452105131; Fri, 09 Sep 2016 13:15:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.200 with HTTP; Fri, 9 Sep 2016 13:14:34 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 9 Sep 2016 14:14:34 -0600 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=94eb2c18ff2c522295053c18cdef Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Following up on token exchange use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 20:15:09 -0000 --94eb2c18ff2c522295053c18cdef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Despite not fully following all of that, I would like to try and understand if there are reasonable changes that could be made to accommodate what you're looking for. What if we changed the subject_token parameter from REQUIRED to OPTIONAL and then require at least one of subject_token or actor_token? That would seem to allow for the 2 distinct functions you mention. On Thu, Sep 8, 2016 at 4:52 PM, Anthony Nadalin wrote: > Things have gotten so muddled not sure where to begin, the original goal > of this draft was to provide the function that we use in daily high volum= e > production of WS-Trust as we transition to Oauth. WS-Trust provided many > options, one was ActAs and the other was OnBehalfOf, these were 2 distinc= t > functions but could be combined (and thus the results are of a composite > nature). There were also other options like delegateTo, Forwardable and > Delegatable. So we have use cases for all these. > > > > So we have straight forward scenarios for (1) a token request to be on > behalf of a given/specified token, we also have a straight forward scenar= io > for (2) requesting a token based upon a specific token. We also have > complex scenarios for combining the semantics of both (1) and (2) where > the token request is on behalf of a specific token and the request is bas= ed > upon a specific token, this happened a lot in our server to server > scenarios for access to backend documents and services. Where we have > chained services this is where the delegateTo, Forwardable and Delegatabl= e > options come into the scenario. > > > > The way that this current specification is structured and written the > Subject is always required which is a not a good thing since there may no= t > be a subject, as basic token requests don=E2=80=99t have to have subjects= (just > authentication credentials), thus you can=E2=80=99t get the semantics of = (2) > without (1). Now the semantics of combing (1) and (2) seem to be not > understood and wanting to be removed. > > > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Riche= r > *Sent:* Saturday, August 27, 2016 3:26 PM > *To:* Brian Campbell > *Cc:* > *Subject:* Re: [OAUTH-WG] Following up on token exchange use case > > > > No objections. Simplification is better, and this spec is already fairly > convoluted with all the options turned on. > > > > =E2=80=94 Justin > > > > On Aug 26, 2016, at 1:30 PM, Brian Campbell > wrote: > > > > Looking for two things here: > > 1) Any objections to removing the want_composite request parameter? Pleas= e > explain, if so. I plan to remove it in the next draft barring an outpouri= ng > of support to keep it. > > 2) Tony to explain his use case and describe what changes would be needed > to accommodate it. > > > > On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell > wrote: > > During the meeting in Berlin Tony voiced concern about a use case he had > for token exchange. Honestly, it's still not entirely clear to me what th= at > use case is or what would need to change in support of it. I'd like to > better understand the use case and see if it's something that can > reasonably be accommodated with Token Exchange. During the meeting Tony > referred back to an earlier email where he said, "want_composite is not > really the effect we are looking for since it provides for a single token= , > the use case we have is where you want the ability to use the subject_tok= en > and the actor_token in combination and not as a composite of only the > claims." > > The want_composite parameter came about during some iterative work on the > document (between I-D publications) last year. At first the client could > express that it wanted a composite token, one containing delegation > semantics, with the inclusion of the actor_token parameter. One of the > other editors suggested, however, that the actor_token token might be > necessary for authorization in cases even when the client wasn't asking f= or > a composite token and that placing the desire for delegation semantics on > it was overloading the parameter too much. I introduced the want_composit= e > parameter to give the client such a signal independent of the actor_token > parameter. My (admittedly incomplete) understanding of WS-Trust is that t= he > client/requester can make such an indication and I was trying to follow > that model. However, I'm not sure it's needed or even makes much much > sense. Ultimately it's the server's decision about how to construct the > issued token and what to include in it. It is the server's policy, not a > client signal, which makes the determination. So the want_composite > parameter is really just noise that makes the spec longer. And, from the > quote above, seems might also lead some readers to incorrect conclusions > about what can and cannot be returned in a token exchange. > > I'd propose then that the want_composite parameter be dropped from the > document. > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --94eb2c18ff2c522295053c18cdef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Despite not fully following all of that, I would like= to try and understand if there are reasonable changes that could be made t= o accommodate what you're looking for.

What if we changed= the subject_token parameter from REQUIRED to OPTIONAL and then require at = least one of subject_token or actor_token? That would seem to allow for the= 2 distinct functions you mention. =C2=A0

On Thu, Sep 8, 2016 at 4:52 PM, Anthony = Nadalin <tonynad@microsoft.com> wrote:

Things have gotten so muddled not sure where to beg= in, the original goal of this draft was to provide the function that we use= in daily high volume production of WS-Trust as we transition to Oauth.=C2=A0 WS-Trust provided many options, one was ActA= s and the other was OnBehalfOf, these were 2 distinct functions but could b= e combined (and thus the results are of a composite nature). There were als= o other options like delegateTo, Forwardable and Delegatable. So we have use cases for all these.<= /p>

=C2=A0

So we have straight forward scenarios for (1) a tok= en request to be on behalf of a given/specified token, we also have a strai= ght forward scenario for (2) requesting a token based upon a specific token. We also have complex scenarios for combining = the semantics of both =C2=A0(1) and (2) where the token request is on behal= f of a specific token and the request is based upon a specific token, this = happened a lot in our server to server scenarios for access to backend documents and services. Where we have chai= ned services this is where the delegateTo, Forwardable and Delegatable opti= ons come into the scenario.

=C2=A0

The way that this current specification is structur= ed and written the Subject is always required which is a not a good thing s= ince there may not be a subject, as basic token requests don=E2=80=99t have to have subjects (just authentication credenti= als), thus you can=E2=80=99t get the semantics of (2) without (1). Now the = semantics of combing (1) and (2) seem to be not understood and wanting to b= e removed.

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= =C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of Justin Richer
Sent: Saturday, August 27, 2016 3:26 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: <oauth@ie= tf.org> <oaut= h@ietf.org>
Subject: Re: [OAUTH-WG] Following up on token exchange use case

=C2=A0

No objections. Simplification is better, and this sp= ec is already fairly convoluted with all the options turned on.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Aug 26, 2016, at 1:30 PM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:

=C2=A0

Looking for two thing= s here:

1) Any objections to = removing the want_composite request parameter? Please explain, if so. I pla= n to remove it in the next draft barring an outpouring of support to keep i= t.

2) Tony to explain his use case and describe what ch= anges would be needed to accommodate it.

=C2=A0

On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

During the meeting in= Berlin Tony voiced concern about a use case he had for token exchange. Hon= estly, it's still not entirely clear to me what that use case is or wha= t would need to change in support of it. I'd like to better understand the use case and see if it's somethi= ng that can reasonably be accommodated with Token Exchange. During the meet= ing Tony referred back to an earlier email where he said, "want_compos= ite is not really the effect we are looking for since it provides for a single token, the use case we have is where you wa= nt the ability to use the subject_token and the actor_token in combination = and not as a composite of only the claims."

The want_composite pa= rameter came about during some iterative work on the document (between I-D = publications) last year. At first the client could express that it wanted a= composite token, one containing delegation semantics, with the inclusion of the actor_token parameter. One of the oth= er editors suggested, however, that the actor_token token might be necessar= y for authorization in cases even when the client wasn't asking for a c= omposite token and that placing the desire for delegation semantics on it was overloading the parameter too mu= ch. I introduced the want_composite parameter to give the client such a sig= nal independent of the actor_token parameter. My (admittedly incomplete) un= derstanding of WS-Trust is that the client/requester can make such an indication and I was trying to follo= w that model. However, I'm not sure it's needed or even makes much = much sense. Ultimately it's the server's decision about how to cons= truct the issued token and what to include in it. It is the server's policy, not a client signal, which makes the determ= ination. So the want_composite parameter is really just noise that makes th= e spec longer. And, from the quote above, seems might also lead some reader= s to incorrect conclusions about what can and cannot be returned in a token exchange.

I'd propose then that the want_composite paramet= er be dropped from the document.=C2=A0

=C2=A0

=C2=A0

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

=C2=A0


--94eb2c18ff2c522295053c18cdef-- From nobody Mon Sep 19 02:21:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2FA12B261 for ; Mon, 19 Sep 2016 02:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kH-2e0R1dRw for ; Mon, 19 Sep 2016 02:21:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B015912B260 for ; Mon, 19 Sep 2016 02:21:14 -0700 (PDT) Received: from [192.168.91.132] ([80.92.115.152]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LaoHI-1bJ8Wt1iKe-00kR4A for ; Mon, 19 Sep 2016 11:21:11 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Message-ID: <2fd272fc-4339-c55a-bec0-34e9cc324f5c@gmx.net> Date: Mon, 19 Sep 2016 11:21:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3s5CBxgRzQYCratBQhZKGTWc+e9XBu3iZWYwtNda11Aoq9UvD8y PYD0ORDPyZXioDtal0XkXdOyR1a4AAebmkNJMFaw7y+d2hFf6R40jSzvkDKcQNfOkadf/si 1FGe2y5poxYxbHgiNB8dcJCR21vNN90i1Rzf2Hav8ul1jbk/w1rNgc4b9mQy0aB6t8XrNsr R6QuyePOrOFvRWjm0O/1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:T6hZF09TumI=:gJ36N9olxJQ5G9pXhIrwwp V24bdh++A/sn/7nhDWdt2u4MoZCBSrYcPps/jP+gudSQaAQQNO/O4ACeiBqQ9wcSpfBxo853g UbUjQ8GkNm0sLhVupMxuvfG/1pIDYxY5SUFERr5HnR9NNefjVZphMLcPuHszdaIfT5bVDmcKJ 33IeIvX96Ew6ew2GalILYxkLJ9cKOLNJeIqBj77e/6/V46covlZWTgREzbnUEaOvE5VyqBLg5 y5fnNyE/HYgymEvhI1/h0hOx4YOM8MEJNvh/nzxzixVqZkGLPBeq44LaMIxO8RBpnr0exAQr7 NUzQ6MZkxUnDq/VRy+BqrPPlk5xOnlorVk0r1bNI80ycFnWywzRqBbk6NOpcME8JROsx/TUdz 6JEglctzC7BTYHnqy9mM8iAHeBSafYGliHtPNtiLTc0eLGRcRd7zCUkhKP1GGRzLKfjVG/9xA wQLTVDls3OPs0KS9QA6F2AnLbkETKiyZA94ClE9GQAitGrRQmK+VgoXKxh1P3xUxGADocvMVG z4YJf6G0PnXhdslE0XweshjiWe/YDqvJ05xWWVLk/4cteSKbUzqOaviJG+jaghUZzcVzXmsp6 bGZntcoPGZDwjhNPaCe/iBu9PqM6wZfrMyYRpgJfnxqkj5aqipNWk4NSHsW9abkCbVhgB1Tn6 mtTh8pZEtAWfpjG6n7C1obi1ytXYbCM2Z+UIJFcLC3iqvvfMnji4dCwJ5FRGZyCa7jfdu6qaz JluxS2kx5+d48KKihufxM7xx42IwBtS0V/S0RjgAcxovGWafVFAoS5u+0/chw1JsCCHQt2J5l Xd3+yGK Archived-At: Subject: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 09:21:21 -0000 Hi Mike, Phil, Tony, I am working on the shepherd writeup for the AMR document: https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02 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? Ciao Hannes From nobody Mon Sep 19 02:26:53 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D9712B09E for ; Mon, 19 Sep 2016 02:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD_KJf6gfltq for ; Mon, 19 Sep 2016 02:26:50 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0101.outbound.protection.outlook.com [104.47.41.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6CF12B0A6 for ; Mon, 19 Sep 2016 02:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9RCydcgx/3dT10Ldyu5ZGdyy51lVOaV03A5ViSonEHE=; b=eKjx3kzRq7/xllcn+rpts8dvrizN55lOm8Q34XkMkLJuBujUKBqCF2hVUMK+/iDe+ew1B9L2M6/dqGWj0Q/WyC0LwGzJMrZEoQsuxqOOwV2aRihvC8s/LknOjMzSGBMLy1zRlwAQQDkqNNlaQs+iRtsqpEdSySqJsspKk9d1Dn0= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2356.namprd03.prod.outlook.com (10.166.74.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Mon, 19 Sep 2016 09:26:48 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0599.016; Mon, 19 Sep 2016 09:26:49 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation Thread-Index: AQHSElc0Yw0c4D4jr0qGZ1zRiDvnCqCAiyJg Date: Mon, 19 Sep 2016 09:26:48 +0000 Message-ID: References: <2fd272fc-4339-c55a-bec0-34e9cc324f5c@gmx.net> In-Reply-To: <2fd272fc-4339-c55a-bec0-34e9cc324f5c@gmx.net> 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: [89.248.140.12] x-ms-office365-filtering-correlation-id: e4900162-6387-49e1-34d5-08d3e06f1526 x-microsoft-exchange-diagnostics: 1; BN3PR03MB2356; 6:2I0OWeIA29A9c+5N9S3iZHx/dmUdH1n8MxwnaFaSCESoF054O1Lle53Ic/I743VYRHsr55pqetK/p79BBaKp3uYcIomfLeKt7T4VKEy5yvGf6Q9tG7+7PmpyCx5cKOsdUyEMUbZyrX1uwI2PDl0kMMq+D7QjNyMKw9dAbIuiIQg4wLT4KcPzP1rnXoQi4Eim/zJsZQgPq0R7MdyHVSmJNyQ9VncdMB6Xhf8pE+iVMSWpaTjyEr73YMOkRRMODgIqtadEdp8Pkj21+FffvQE2NfPhDzNO8ADRrFyy7O3wWP9z/QDjyHMindr9iuaFk8UcwNg3gVSWh4pJf7fAiN2/zQ==; 5:AkvYoonFk0HEq5Qn8x5p7/AiCEc7oy/UJydhOJdcMDlNcNdAgmJJgcrkoxM8XSbqzaT4paHPOruExm6gDzuHH0043Pb6GZHZohGtxHj/LuRgnsvUM68DQZrzRmdNt2WfLbsmW9ZiS0t0gKqByXWQIQ==; 24:f6Wgi3f4Wn5ezs2JL9Igg4+OD9FO/SL9fYZVR97NJ0gH7r777C5pWe3TwKkoTdXlK43JmkbjaFiuefdUhxz1pq+6joNHTb0EuiaMUeRQyJI=; 7:C+NttWudmHXzA5nONoKei4RlDNVzWyuIq3VIGnArUuHNOTAojCl6nx19FV4Ad7w7N/KA32O9RR4kl3QGwPkAssO10gDbN5JPOI+V7Gk6R6A4Q/RjN6TDADWPFjLO/saVQw7qDhNuppOfYwef8V9XNTP42wvSrTNcvBTzOt+UQLWe0LxrnNJfXTuvdYnQktpSw7FmBc1f+uU1Gffp72JhRokhfoQUNaugIKc7c/rcnVdhvB/TRcwZUeQBFRDN3XNjKsGw/fUSLpmuFJ3zldju7ByY00KlGBFFElfdGFHuGmICdfOEg27b1J2vzWSUa+VT x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2356; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB2356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2356; x-forefront-prvs: 0070A8666B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(13464003)(377454003)(6116002)(102836003)(19580395003)(10090500001)(92566002)(3846002)(99286002)(106116001)(19580405001)(105586002)(122556002)(107886002)(5660300001)(86612001)(76576001)(189998001)(5002640100001)(8990500004)(3280700002)(97736004)(106356001)(5001770100001)(87936001)(86362001)(33656002)(15975445007)(2501003)(77096005)(54356999)(76176999)(50986999)(101416001)(66066001)(586003)(2900100001)(2950100001)(74316002)(7736002)(81156014)(7846002)(10290500002)(305945005)(5005710100001)(3660700001)(9686002)(81166006)(7696004)(68736007)(10400500002)(8936002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2356; H:BN3PR03MB2355.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:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2016 09:26:48.7688 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2356 Archived-At: Subject: Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 09:26:52 -0000 I am aware of no IPR on this specification. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, September 19, 2016 2:21 AM To: oauth@ietf.org Subject: [OAUTH-WG] Authentication Method Reference Values Document: IPR Co= nfirmation Hi Mike, Phil, Tony, I am working on the shepherd writeup for the AMR document: https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02 One item in the template requires me to indicate whether each document auth= or 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? Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Sep 19 03:07:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB412B2BF for ; Mon, 19 Sep 2016 03:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_CMlNJ6b6RO for ; Mon, 19 Sep 2016 03:07:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B67812B2C1 for ; Mon, 19 Sep 2016 03:07:16 -0700 (PDT) Received: from [192.168.91.132] ([80.92.115.152]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M2ts6-1atPsq1fwU-00sh0f for ; Mon, 19 Sep 2016 12:07:14 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Message-ID: <3d39ebb7-29d5-256b-768f-6d97dabd6e23@gmx.net> Date: Mon, 19 Sep 2016 12:07:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:B1RkmqPXADAqtT8CyptP3x+z0iCE9LFhAVzl+b8rgmwVmj34N8w rv8ILDIe3wCO+EplZ9sxq3KpdYkeRhadMVZdCK474eX49a7yaLYkqt+8hvXV7Ni63XVxEi9 lappsfZ8PqvfMwnQS1LR5MqzqQqaZ+nzEPZGyptAGEmN2oGKK42uqhz80zobOHjZaNj57by e302ufTpOb7v+bpY/fIVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:i8MwNJ7KhfY=:K4NkhhvUwRZS9yuXI8e/Bh eB7uEIPafn4cf2jJU7wyPNnjWFWqbY/d3YNswbqqedICzHyS0lGqeGDk8xl7kk6yzXipo+Pb6 ifdn35y8L7V5mJY3qq++bFzjiy20Hxmdl4zPKkvKl4SqjCPc6q3b/CgoxcCgDDff4V9Gwj8hp PZYuD3BqITOOwPvP3RQYvuMv8PTAzenUTQg8FEbdRnheZITiohDlR+r6673XAbsuaRxz7Pe3E UmThpSDDBtljBTAm7tSH8ompKWEOkT+r4eLSF8f2V2dxfNzzZLwxnGyRkm8rpkLtOQoQzvBW1 RPuzkRVVcg8AdyfUg6vW+Fvt2vXy380j8LcRQKA+4o+ye/7N1htv+POWLIRjzG1+N6it8ZPV6 3yvtOkowtH1wbdJbLcgeCyVGUskZx0srq2S57EAgYBkx70r7wqC5oF640C4bTOujk69NEImpi XD/Mye3yCa1eyfbDWwdh69mhaQNqJhu2BplN7zu9jNPveg89HDLbhXw+dn5MYEbrU4JiwjoOm rKMV6kJFnR+BOw59q19Rcgflnti3OLf3AMpzZwrEqrBXrzhFTyagKcn3MPFBQoBgk23Cx9e7J 5f35+9ebV6VdPdoqibasniH1mUvcNK6QFaRgx3J67ldt8ZGNpVC/CN+zP5hpdbBtWVk6eAEfQ 2LWrci58jGp0++/4bRmWwp56Buxob07N955prHMjCvRofELpSrceUZriHIIalwcVnCeN4z8/D ptY7Oib1X/cvsFWxMA/+31g+4AGTaFkeO6pF8TlQrdb0ZVTeN8A5Rxmnk8zLx7JEg/I3ExYHx JgdxV9O Archived-At: Subject: [OAUTH-WG] OAuth 2.0 JWT Authorization Request (JAR): IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 10:07:23 -0000 Hi Nat, Hi John, I am working on the shepherd writeup for the JAR document: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08 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? Ciao Hannes From nobody Mon Sep 19 03:07:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F6F12B2BF for ; Mon, 19 Sep 2016 03:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNMkvH3MKN_3 for ; Mon, 19 Sep 2016 03:07:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F44912B2BD for ; Mon, 19 Sep 2016 03:07:17 -0700 (PDT) Received: from [192.168.91.132] ([80.92.115.152]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LpKrt-1b6ntm3oBx-00fDHK for ; Mon, 19 Sep 2016 12:07:16 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Message-ID: <78c4a842-3d86-7f67-bd4d-9243377ce251@gmx.net> Date: Mon, 19 Sep 2016 12:07:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4eMB4jWge/Z1/Fb9kxD5k0mUijVb2SAB+LzZ+FF66/769pGNag4 pM5oIhFd/HuQfAxZ4hH3rGa5u7dNlyRNQEypF6UN/0aAC3ge+GCAhZyNfJF3Dc41Cj8l2R2 0Ig3dODkrWPlHEgopOsAZdpE78bNvWI4UKipi/PezztnjIOnbKBjnRUxcmTg86oE8aPPBbI T5csvwg4mQ8jVmHC5c77A== X-UI-Out-Filterresults: notjunk:1;V01:K0:zrXuAbBdhxE=:yZfeBikarNxKGM8ojEMiKj QYiep9pVMtw0MAeBl9R7ZhdE1ScDHjRlpLlf+8mHNhGl0v0kbcecqdj9CeYlYHe/Js2eiOblH 9ryh67ztcMC2AlhtvblkQMzcvKeaY3JoRplJNuuOb3rEhYqsn5Q51gqK1hFph2KLTcF+t6/vm 61TYhGZZNJvZe4xEfZMT5AT1Dg2MXQAdDRRraFa+blqql9oilm9xzEThe0jP5lR12XYT8Z15F mxeh8GBe8doMO+9oZmMTSt6LjTneK/6ohThkF1wvgrKtXKxMKejc5VqUB2DNV5eLcCZpnTu/n GzrtnQW7Sn3gW0+sZIYECo3Qjr7viWiKd41d+qnz3xbIzRCWtTahUGGHcrRtn5Cwn1GfpXnTw FjOhltkqf0fERgJ2rg5rqZPZkEGTDHebJhNmSjVwM8tF0XjaQNow6cJ0ncmhuj/z1K2FUf/b9 SxwQ5QtPb6PyjbLC2n0FNN0UCDzIb21b5vWSm7ZSPbfkjLAVUPA6eDfanqs6Z2C4ro7N52m43 k9Lmjo43WdqSsOHKkO56Sk7iwYmnDXUN2KTWaXer8RjeK690fwd4JzmXIIoN2oG2Aww25Jbx9 BreiRHN2aPcSUOKL5sSeOEhx8I/ESH/cueyQ07qf1fTlPilC4AbhFSAn1tri6RBwn6ZV1VXrt fOGFQ1QQzzuHuc1WVk0H+Mq31sXSf9MEMEUTmOfle5+vLjCaWGUWV9vwRdOsT7DbwRgGHWN4l 67EcuOLh/GepLBR0yFkRQWt1HxCwm+sLwgm0PYe6EvPPOXw625vEnXl/qQTBaDM9M+r+Qjkyk zfyPQHI Archived-At: Subject: [OAUTH-WG] OAuth 2.0 for Native Apps: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 10:07:24 -0000 Hi William, Hi John, I am working on the shepherd writeup for the Native Apps document: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03 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? Ciao Hannes From nobody Mon Sep 19 06:29:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4936012B396 for ; Mon, 19 Sep 2016 06:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUCsEzpG1sRp for ; Mon, 19 Sep 2016 06:29:36 -0700 (PDT) Received: from mail-oi0-x263.google.com (mail-oi0-x263.google.com [IPv6:2607:f8b0:4003:c06::263]) (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 4EF6312B10E for ; Mon, 19 Sep 2016 06:29:36 -0700 (PDT) Received: by mail-oi0-x263.google.com with SMTP id w11so9073701oia.0 for ; Mon, 19 Sep 2016 06:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:content-transfer-encoding :mime-version; bh=vUD8r8mluUGrWdo+CP0byC/yeviJ5duMmY1rLFDR+mg=; b=Vdcq7UnENFXZgv1oOhEPPGPXyGRsuV0+D85Z9OZl72d/wD1dldWuWFmH+U6RwNMekS XYnYKYrdOKfYUdDUurkT36dcT3ICN0A63pTuUWGu+MIQtUeNbvU7kJAcZYG+7sastlVJ YhSIW3T7tifDQ1MBoHfatWJdt/MvX/71wgBDnel6pdRdxxtyUae3wO/uWEQEbBM7G6yX HR7X14YYuy+geXD2bKZrD7HNhfA3GPsQtRSroCbk5uo8Q3JEDQQaHbwIMrUTtH0oAGVn TJMvtim46/4YNa/bf9Kr/j1JZYtuXPjmU6WJSWgxb+DtmPddcC0HS2M55FxiFUoFshHs YPEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language :content-transfer-encoding:mime-version; bh=vUD8r8mluUGrWdo+CP0byC/yeviJ5duMmY1rLFDR+mg=; b=lxQASX65Vc05n1HDl8XkLqrsVKs6nWk3ZJdDmzs0/ZjaOUlWmEwkvj5fgr6d+KOKED NZDS/GwFpfEdAshx5cSa11LghobbsDR6HUaBWlS90vsYxYzfb6SwdsKWLJWdIJwxTyxX 9eiyoBRl9AY4+0oeE0tvem3W6tkYpYKfQv3fKpdVagfgxrgIWu3B79SMWWfR5+IdUaYs WxbppnvwEq/ih5cIFSN2O36WlhUCJY1nEDPc+LNWVX6v9VCWoH5zgxdduEM6UHvufIno Wf65WDPUz+4Y1hz7bBXKIuS6WbsPqWs7eiWZ9KH4QwqvHym4SfLjeqiOGBFQC0W1ybMY w7kw== X-Gm-Message-State: AE9vXwOBgQvGcuHRCMciE9UC7oqnvj5z6vn2BBwwi3J0gL7YdbeGQWcW9GiM+yCnPpePXs1wK7VsZM/gfZ95cNwsWc2EGgzj X-Received: by 10.55.164.193 with SMTP id n184mr31050355qke.197.1474291400031; Mon, 19 Sep 2016 06:23:20 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id n66sm4355782qke.0.2016.09.19.06.23.19 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 19 Sep 2016 06:23:20 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u8JDNJ4I004709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Sep 2016 09:23:19 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 19 Sep 2016 09:23:19 -0400 From: "Hollenbeck, Scott" To: "OAuth@ietf.org" Thread-Topic: Identity Provider Interop Testing? Thread-Index: AdISePxkx9pkv0DMT9uAAN0bgJZuPw== Date: Mon, 19 Sep 2016 13:23:19 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A4773F3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Identity Provider Interop Testing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 13:29:41 -0000 I'm looking to do some OpenID Connect interoperability testing with someone= who has implemented an identity provider. I have a relying party implement= ation that's been tested with Microsoft Hotmail and Google Gmail. I'd like = to add support for at least one more IDP. Can anyone help? Scott From nobody Mon Sep 19 06:35:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39A12B3BD for ; Mon, 19 Sep 2016 06:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfVk8A6MFUzs for ; Mon, 19 Sep 2016 06:35:42 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D564B12B0E7 for ; Mon, 19 Sep 2016 06:35:35 -0700 (PDT) X-AuditID: 1209190d-953ff700000011b2-74-57dfe9a5ead3 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 (Symantec Messaging Gateway) with SMTP id 44.68.04530.5A9EFD75; Mon, 19 Sep 2016 09:35:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u8JDZWJv005755 for ; Mon, 19 Sep 2016 09:35:33 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8JDZVAM019679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 19 Sep 2016 09:35:32 -0400 To: oauth@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F4A4773F3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: Justin Richer Message-ID: <1cae674a-853d-84ae-b7d2-ae63c0eff425@mit.edu> Date: Mon, 19 Sep 2016 09:35:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A4773F3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixG6nrrvs5f1wg80zVSxOvn3F5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNXrPjEVTGarePi8k62BsZO1i5GTQ0LAROL50vvsILaQQBuT RP96uy5GLiD7GKPEh1MvmSGcj0wSk7adZgKpEhawkvi3cy2YLSIgJPF8Zx8TRHeYxLyrV8Am sQmoSkxf0wIW5wWqf7//N9g2FqB4y6IXLCC2qECMxP5ZM5khagQlTs58AhbnFAiXaL65Bsxm FrCVuDN3NzOELS+x/e0c5gmM/LOQtMxCUjYLSdkCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealF ukZ6uZkleqkppZsYQcHHKcm7g/HfXa9DjAIcjEo8vCse3w8XYk0sK67MPcQoycGkJMq7eDZQ iC8pP6UyI7E4I76oNCe1+BCjBAezkggv62mgHG9KYmVValE+TEqag0VJnLdrxoFwIYH0xJLU 7NTUgtQimKwMB4eSBO/3F0CNgkWp6akVaZk5JQhpJg5OkOE8QMMZXoIMLy5IzC3OTIfIn2LU 5Vjw4/ZaJiGWvPy8VClx3nPPgYoEQIoySvPg5oCSRsLbw6avGMWB3hLmXQ6yjgeYcOAmvQJa wgS0hLEHbElJIkJKqoEx65BvmEPXy3SNe1cD/qs/Yg9T2KXBVsbvP2u9wk8bX7/w97tFnr2P fpwRsv1XKuvKPzN8RRVeOxp1LGOzLI3bG5MuxvE+RmpO0opDz6aKMO/NXCzRFyZxzLCcie9X VYj8+rzglUvL/+8+dmtWFcNqFYH9kq9msnx/cKWjpegjQ9W9tgtnTnoqsRRnJBpqMRcVJwIA ByhQhvUCAAA= Archived-At: Subject: Re: [OAUTH-WG] Identity Provider Interop Testing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 13:35:47 -0000 You're better off contacting the OpenID Connect working group and the interoperability list there. http://openid.net/wg/connect/ While there's a lot of overlap in the communities, OAuth and OIDC are different protocols and the discussion you want is better held there. -- Justin On 9/19/2016 9:23 AM, Hollenbeck, Scott wrote: > I'm looking to do some OpenID Connect interoperability testing with someone who has implemented an identity provider. I have a relying party implementation that's been tested with Microsoft Hotmail and Google Gmail. I'd like to add support for at least one more IDP. Can anyone help? > > Scott > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Sep 19 07:18:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF59412B3AE for ; Mon, 19 Sep 2016 07:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSebSoakyrM5 for ; Mon, 19 Sep 2016 07:18:46 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6CA12B347 for ; Mon, 19 Sep 2016 07:18:46 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id d69so86570536ybf.2 for ; Mon, 19 Sep 2016 07:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/DYXvV/zSb3U+mIiuORkqLITv2e/cLvb/NYK7b+BkHw=; b=r4ROHarUIsZDpMsT0BMv+/XnC3M3NZHAVgzeDS5ifRgeCyQk0r2FwuK+ULvnVnF1mS EfYcVoHkbYEdRRRn5QsJBn/pH/1qmqSNQ2s1w/AtAvXEkSX7NTPBowurvFLOno6a2s/b gZLrgoH+0Crun+I1bnTChV7QVukUttn7l5UVMGUg212SnXsJvdAfaVwW6OwdcTm9Zs0e BAUn87vkpGKMEsQTEUNrlwa5UrNvkQaElTbTi6WFnsq7/+jWsathUZ7MGF1+abMViAzC 1hcCUohsfRROZHeInCqbzfO4l4zr63W5QsQTjCa057QigNYNJ9GnEWKPDcLLdL4z/gT/ UzUg== 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; bh=/DYXvV/zSb3U+mIiuORkqLITv2e/cLvb/NYK7b+BkHw=; b=C4J27/yAMz47D/2ihKpN5C25t3Bb8C6+p2XBZrlrRdRjEB4dK+14Y7aPKqUhCLfFDk 1DqOCMETB0xOb4sLBvLv39pj2mlKhykbN5f0zISK5ah5fe7Z5xZutcnz5bs6vvTonW+m yYLUQnyYY/9JSjq+l+lgUx9Jw0daO0dIa6lY/Lmph7q56YErR4ulb66eAky+fEyy0fZ7 WkcIWtyTvt0TeXySy4H3CDHpmY0FyPFq0x3YB2Jwlv6uVpzqtCRWMIlDMlR5sL6SchiH 7+i/1J20ct6l0bh2uJFt4nsUPuZeUHTaWCtSlw8rPDEfwzU5rkFOqr5Lr+42lcPDf7w4 saUQ== X-Gm-Message-State: AE9vXwPjExiKj6E8It6+bKx1seWs1uWaWaq5O8C1fevOpS/SxffOXSfjpZeAUg0h7lZdoLfcotUqznsqsAOiAg== X-Received: by 10.37.12.136 with SMTP id 130mr22425812ybm.161.1474294725386; Mon, 19 Sep 2016 07:18:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.70 with HTTP; Mon, 19 Sep 2016 07:18:43 -0700 (PDT) Received: by 10.31.97.70 with HTTP; Mon, 19 Sep 2016 07:18:43 -0700 (PDT) In-Reply-To: <3d39ebb7-29d5-256b-768f-6d97dabd6e23@gmx.net> References: <3d39ebb7-29d5-256b-768f-6d97dabd6e23@gmx.net> From: Nat Sakimura Date: Mon, 19 Sep 2016 23:18:43 +0900 Message-ID: To: Hannes Content-Type: multipart/alternative; boundary=001a113e5f5866f07b053cdcfd06 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 JWT Authorization Request (JAR): IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 14:18:47 -0000 --001a113e5f5866f07b053cdcfd06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Confirmed. BTW, I was waiting for your confirmation about the draft title change as discussed in the list. Shall I just push it? 2016/09/19 =E5=8D=88=E5=BE=8C7:07 "Hannes Tschofenig" : > Hi Nat, Hi John, > > I am working on the shepherd writeup for the JAR document: > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08 > > 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? > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113e5f5866f07b053cdcfd06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Confirmed.

BTW, I was waiting for your confirmation about the draft tit= le change as discussed in the list.

Shall I just push it?


2016/09/19 =E5=8D= =88=E5=BE=8C7:07 "Hannes Tschofenig" <hannes.tschofenig@gmx.net>:
Hi Nat, Hi John,

I am working on the shepherd writeup for the JAR document:
https://tools.ietf.org/html/draft-ietf-oa= uth-jwsreq-08

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?

Ciao
Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113e5f5866f07b053cdcfd06-- From nobody Mon Sep 19 07:37:04 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F0A12B3E6 for ; Mon, 19 Sep 2016 07:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtUHhqZpkMhb for ; Mon, 19 Sep 2016 07:37:01 -0700 (PDT) Received: from mail-oi0-x264.google.com (mail-oi0-x264.google.com [IPv6:2607:f8b0:4003:c06::264]) (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 EB8FD12B3E5 for ; Mon, 19 Sep 2016 07:37:00 -0700 (PDT) Received: by mail-oi0-x264.google.com with SMTP id h186so7042905oia.1 for ; Mon, 19 Sep 2016 07:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=BZN4jiis5F6k/hTX9mWKyzTYwXaN5WeL1ZLHPGGuHrk=; b=eTe5/XVNHIgnuQwJUnGcd9NH12JC6aldt6yl5aRad+wYHRq257RKerB8W7WDV6yWK4 QCYS4s919vyOptRUYmbYBBE/qCeWRH3LjK1bw3MblSVQZK5dG7d3SU7TWZ8hz7HNaE1q cR2b31K96JPz8wgIrAQNTN3FRIxgcBJIEwJ8iKUkneWMi4YtJJMNRzA1ps/35/AKe6t9 p9tMnh4ewageR+i8L+4cbP/VKyzEkiuT35GKPZ92/ldgKlAtrgO0cwuwmy01GdhZ6+vZ rr/rj67+LfALCitW7NMJmtfMxhKhJtxeDkh3sxfplKSCkKF/61XR9Ux1ZAdobR5ETSNl SJXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=BZN4jiis5F6k/hTX9mWKyzTYwXaN5WeL1ZLHPGGuHrk=; b=lB+j4notKxIx+YC4Ctc3yUZEFTTxpcd7An/mzF7GuP1zBV7+tGouoZNqk6oNdy1YbX u3392p+w/FZmRQe1p3BABvQu/SQOedwg9K/rGKVlZAgzlzUhsxiKttbyLFNdJBK+6chg 2TahiRVh+/vi2p2heP2RyffwxOih3F/hve0BbqtQE/AO4Wg5HPiYS5pgNgp30+pubqKG qQbMA6zBS2I6ulJ5z5DMDuRSXkA0T/e67IXGAaTfmNfXK/imuFdOod6FWXnhzbCRTgqH c0nI4xWxfQ6VknLN++xR6WyTHyq7RbMsWzhqlWrZ7G+WaPdVxv3uiW4dnRXBn+SuY998 AGVA== X-Gm-Message-State: AE9vXwNxxTVzjmBbXPzG+my4O3vzQNaMxX3cZancO8CGp+jZdyYTo9VWHeT088ZqOK12vPLakKMgbBgwg1LBtBYylZUAsHkV X-Received: by 10.200.41.71 with SMTP id z7mr30797514qtz.107.1474295820221; Mon, 19 Sep 2016 07:37:00 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id l24sm2828840qki.2.2016.09.19.07.36.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 19 Sep 2016 07:37:00 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u8JEaxuu013973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Sep 2016 10:36:59 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 19 Sep 2016 10:36:58 -0400 From: "Hollenbeck, Scott" To: Justin Richer , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Identity Provider Interop Testing? Thread-Index: AdISePxkx9pkv0DMT9uAAN0bgJZuPwAIzpeAAAZl5FA= Date: Mon, 19 Sep 2016 14:36:58 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A4774AA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A4773F3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <1cae674a-853d-84ae-b7d2-ae63c0eff425@mit.edu> In-Reply-To: <1cae674a-853d-84ae-b7d2-ae63c0eff425@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Identity Provider Interop Testing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 14:37:03 -0000 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Monday, September 19, 2016 9:35 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Identity Provider Interop Testing? >=20 > You're better off contacting the OpenID Connect working group and the > interoperability list there. >=20 > http://openid.net/wg/connect/ >=20 > While there's a lot of overlap in the communities, OAuth and OIDC are > different protocols and the discussion you want is better held there. Understood, but there's this little detail: > Please note that while anyone can join the mailing list as a read-only > recipient, posting to the mailing list or actively contributing to the > specification itself requires the submission of an IPR Agreement. Sorry for the off-topic post, but I thought that a note sent to this list m= ight just find the right people without having to deal with the overhead of= getting an IPR Agreement in place to gain posting privileges. Scott From nobody Mon Sep 19 08:49:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A8012B41A for ; Mon, 19 Sep 2016 08:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ozpjujvzLjH for ; Mon, 19 Sep 2016 08:49:15 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725AE12B3DB for ; Mon, 19 Sep 2016 08:49:05 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id g192so155395377ywh.1 for ; Mon, 19 Sep 2016 08:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=D0yQwXeZCYIIP9Gcv4JHWhhPMmgBh7icNkNX2ERGU9M=; b=xF7bSZRBe9VKEJpHyY9aoD5Ks3c2Oe4si8LhsfqBohN5YyQ6Pb4SeWOSrBoc635ZkY ceQVWo5GoahQj2G1PBfuYNppwZJPhL6fHJC6JrqMMJcBcxObikueXq9GUqFyo+33zVZH jxP0EWWrVJOqvzl9/0kw9+ykaYbdvPBypwp7RA2UM43OuLHdq/0d4uIyhSesEK8KbW+9 i+oIsQIK5IEMz9scoaWz5rtEBxGtGziiyyH25cATUk47SIbTBWfpep5Ke9yVLfO7aHCU oVbBImVEUa1ZfzdtYPSUjsKqXgR5NbNxgsxWV145maPR58AbX3IdvPzlwRpchhnNir2d E0Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=D0yQwXeZCYIIP9Gcv4JHWhhPMmgBh7icNkNX2ERGU9M=; b=H9bxJMu6ZSarBhl9AzieDL3gkDfY+bG1XXZWjkzviefh9wzIhvi8Yudp2gL3wUAbzY xt+mZr/INqNLRVc7JPha9ocbdr5IQQnwD+aTmQMld6Cm7oR/qhl0Z5Gthz/+6HHNjT7O ssyhg4tjlkVhBKdeYo+mEuScYj3Gu1CYlL4i+bKZX3OxBCE1K3yVzYhCnGE5gIi0WlSq DHVCbnqtoILxxW8VzTgUchNkDxc1sGG2sjcxspr3IWeZ511Gwstnx6mnHpz6YDevxO0T ZbZmgmirtuzhBufpCQiyaof1B7niYOzU0eUhSo7gbSZve+qHx5mC8KdvJKCLLCEbYIOZ /UJQ== X-Gm-Message-State: AE9vXwMLzaBRdqN/3Z/2c/pXchHfBYVInmJ3Ny4OoJkfOLHXT5iYUNMse+kzAxrgVIPVReq9 X-Received: by 10.13.203.79 with SMTP id n76mr24925538ywd.122.1474300144676; Mon, 19 Sep 2016 08:49:04 -0700 (PDT) Received: from ?IPv6:::ffff:100.47.96.93? ([100.47.96.93]) by smtp.gmail.com with ESMTPSA id p71sm3217252ywe.40.2016.09.19.08.49.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Sep 2016 08:49:03 -0700 (PDT) Message-ID: <57e008ef.4ae60d0a.20a32.de2a@mx.google.com> MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" From: Date: Mon, 19 Sep 2016 11:49:04 -0400 Importance: normal X-Priority: 3 In-Reply-To: <78c4a842-3d86-7f67-bd4d-9243377ce251@gmx.net> References: <78c4a842-3d86-7f67-bd4d-9243377ce251@gmx.net> Content-Type: multipart/alternative; boundary="_19B5A7FC-FA01-4F4E-9B3E-9B45EBADCABC_" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 15:49:18 -0000 --_19B5A7FC-FA01-4F4E-9B3E-9B45EBADCABC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I know of no IPR disclosures for this document. I have none to make. John B. Sent from Mail for Windows 10 From: Hannes Tschofenig= --_19B5A7FC-FA01-4F4E-9B3E-9B45EBADCABC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I know of no IPR disclosures for thi= s document.

 

I have none to make.

 

John B.

 =

Sent from Mail for Windows 10

 <= /o:p>

From: Hannes Tschofenig
Sent: September 19, 2016 6:= 07 AM
To: oauth@ietf.orgSubject: [OAUTH-WG] OAuth 2.0 for Native Apps: IPR Confirmation

=

 

Hi Wi= lliam, Hi John,

 

I am working on the shepherd writeup for the Native Apps document:

https://tools.ietf.org/html/draft-ietf-oauth-native-= apps-03

 

O= ne item in the template requires me to indicate whether each document

author has confirmed that any and all appropriate IPR di= sclosures

required for full conformance with the pr= ovisions of BCP 78 and BCP 79

have already been fil= ed.

 

Could= you please confirm?

 

Ciao

Hannes

 

___________________________________= ____________

OAuth mailing list

OAuth@ietf.org

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

 

= --_19B5A7FC-FA01-4F4E-9B3E-9B45EBADCABC_-- From nobody Tue Sep 20 05:10:33 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 259EB12B0E2; Tue, 20 Sep 2016 05:10:28 -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.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147437342815.29147.13068408384803220459.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 05:10:28 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 12:10:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones John Bradley Brian Campbell Filename : draft-ietf-oauth-token-binding-01.txt Pages : 12 Date : 2016-09-20 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens and Refresh Tokens. This cryptographically binds these tokens to the TLS connections over which they are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 20 05:17:00 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6309612B2DD for ; Tue, 20 Sep 2016 05:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0URD64WwFWE for ; Tue, 20 Sep 2016 05:16:56 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0120.outbound.protection.outlook.com [104.47.37.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923E712B2DC for ; Tue, 20 Sep 2016 05:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=55/GVMyuO9+t4LMTDgc1QljMeI4Ovxp0Nkl2dZtINaQ=; b=Xhe3b2/rwZeuLT5r3UIk2qmUC9zOC46aa2jKki/V5DdtWnHRQuk77xS53F1/kK+T6sRAgF9gRRxYP6/5nU/jUBgdI7dqAmMv5Lc5plt3F3B7VXXFwwZgZm4WSxtYibgHAh2NtLaBD95Kl3VcHfCY34i1RAwGDXmQOH26vdcckcs= Received: from CO2PR03MB2358.namprd03.prod.outlook.com (10.166.93.18) by CO2PR03MB2358.namprd03.prod.outlook.com (10.166.93.18) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Tue, 20 Sep 2016 12:16:54 +0000 Received: from CO2PR03MB2358.namprd03.prod.outlook.com ([10.166.93.18]) by CO2PR03MB2358.namprd03.prod.outlook.com ([10.166.93.18]) with mapi id 15.01.0599.016; Tue, 20 Sep 2016 12:16:54 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Using Referred Token Binding ID for Token Binding of Access Tokens Thread-Index: AdITLN3AvEZSb1qWQgWbF/NlQqhekw== Date: Tue, 20 Sep 2016 12:16:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [62.28.231.86] x-ms-office365-filtering-correlation-id: a4292c66-1beb-48cb-eee0-08d3e15002a8 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2358; 6:P/ZvNfXRE7Attgr8KMaOJeP5vtGVg+HAQxQx27+6q9mFl2dZnwFNRqOX27u7upVnoc2RVoobKTyyu2QHOJ6Ew/wdP8yo04iXMBTIdh7RscVwUS5RggqRpbzpiTm8pR/+94RBSuihsr0w5qym3/OTuPQDle394coty5lA8LqacMQUiUxetMwDVFKfzTfuYLKBP7yv0BkbRwePCYjYWDu0huFKsIGQAO6G+0XXIyE7tOJnmRp5yaccsTMnTU2yk07gyGOaLbuPlWz6w7zJ9RqoyfLEcnDuEVccH6NI91TW0VcNqOWHyy3mf8+1Naz+iqf9A6VUcDAmlBULWPlMiSvcxg==; 5:6+t7XBYVo/RqKdI58bObBdf9kCrEVXotaxksJ+SWKRsqau0s60HOw+4lDt7/6Tk/JkipUJEJXMtVPXFTrRH7PYso/bjaLLGkuISsMRY+apRdSrtcrjHVfGy6gBbzHWKNzAMzr6e/4HVwL51Fq7MPqw==; 24:+Cxfka44/YgYSq8NR/ilVvAJMivtvX3RNsggwo90dXM03RqTuNtnTvU1jj/fmHDXbWIAb+7N5e9VLeRpwVDJBLyNmJyzN4JqXpXag/TOVD4=; 7:qrPq1XFoGdqk44R0cPs3p+4LRdjE1k4CS08s9D1icnmBCmX9prShYK6kjEBy0odgRGf9as2vx7JQKvN1vJETa6m14V93Jrz8UuRC7TscW31Sv2j65RIKxmwdw4kBNrVtbp7OpHjbuiQS1RMte/tp2wjKrMFbvIw/EEPLjx7TqG3H0kuJdfRu7sj9uGl5nybS1IWlF8Xqa/H/C4Frw/J/dudzWywjYz9XQQtMUEjNkPcePPkxigSHG6svq52xE5agqPBU0VWOjvAitZe/1a64S2A2eJ61xKOiLIGtid6pKTZXJXrric7xSHzWy4a/9IqV x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2358; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2358; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2358; x-forefront-prvs: 0071BFA85B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(189002)(199003)(5005710100001)(229853001)(9686002)(10290500002)(10400500002)(2351001)(92566002)(19625215002)(50986999)(101416001)(97736004)(19617315012)(68736007)(110136003)(3660700001)(7696004)(33656002)(3280700002)(19300405004)(19580395003)(2906002)(10090500001)(450100001)(189998001)(54356999)(107886002)(11100500001)(1730700003)(8936002)(77096005)(86612001)(81156014)(81166006)(86362001)(8676002)(8990500004)(66066001)(76576001)(2900100001)(87936001)(106356001)(6116002)(586003)(3846002)(790700001)(102836003)(7906003)(5002640100001)(7846002)(7736002)(5630700001)(99286002)(16236675004)(15975445007)(2501003)(5640700001)(105586002)(122556002)(5660300001)(74316002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2358; H:CO2PR03MB2358.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB2358D7F80F3AB286A38082F6F5F70CO2PR03MB2358namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2016 12:16:54.6380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2358 Archived-At: Subject: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 12:16:58 -0000 --_000_CO2PR03MB2358D7F80F3AB286A38082F6F5F70CO2PR03MB2358namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth Token Binding specification has been revised to use the Referred = Token Binding ID when performing token binding of access tokens. This was = enabled by the Implementation Considerations in the Token Binding HTTPS spe= cification being added to make it clear that Token Binding implementations = will enable using the Referred Token Binding ID in this manner. Protected = Resource Metadata was also defined. Thanks to Brian Campbell for clarifications on the differences between toke= n binding of access tokens issued from the authorization endpoint versus th= ose issued from the token endpoint. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-token-binding-01.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1610 and = as @selfissued. --_000_CO2PR03MB2358D7F80F3AB286A38082F6F5F70CO2PR03MB2358namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth Token Binding specification has been revis= ed to use the Referred Token Binding ID when performing token binding of ac= cess tokens.  This was enabled by the Implementation Considerations in= the Token Binding HTTPS specification being added to make it clear that Token Binding implementations will enabl= e using the Referred Token Binding ID in this manner.  Protected Resou= rce Metadata was also defined.

 

Thanks to Brian Campbell for clarifications on the d= ifferences between token binding of access tokens issued from the authoriza= tion endpoint versus those issued from the token endpoint.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oauth-to= ken-binding-01

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft-ietf= -oauth-token-binding-01.html

 

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

 

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

 

--_000_CO2PR03MB2358D7F80F3AB286A38082F6F5F70CO2PR03MB2358namp_-- From nobody Tue Sep 20 21:02:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EFE12B53E for ; Tue, 20 Sep 2016 21:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg2-PDjf1KVL for ; Tue, 20 Sep 2016 21:02:54 -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 90C0E127071 for ; Tue, 20 Sep 2016 20:53:39 -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 u8L3rZL6029540 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Sep 2016 03:53:35 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u8L3rYt7019777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2016 03:53:34 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u8L3rWYR012218; Wed, 21 Sep 2016 03:53:34 GMT Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Sep 2016 20:53:31 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-CE715618-4520-4B88-8C95-FDC9123A1A22 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14A403) In-Reply-To: Date: Tue, 20 Sep 2016 20:53:30 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9C98A9AF-69FE-4CFE-8DD0-68B6D0D87BDB@oracle.com> References: <2fd272fc-4339-c55a-bec0-34e9cc324f5c@gmx.net> To: Mike Jones X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 04:02:56 -0000 --Apple-Mail-CE715618-4520-4B88-8C95-FDC9123A1A22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I am aware of no IPR.=20 Phil > On Sep 19, 2016, at 2:26 AM, Mike Jones wrot= e: >=20 > I am aware of no IPR on this specification. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig= > Sent: Monday, September 19, 2016 2:21 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Authentication Method Reference Values Document: IPR C= onfirmation >=20 > Hi Mike, Phil, Tony, >=20 >=20 > I am working on the shepherd writeup for the AMR document: > https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02 >=20 > One item in the template requires me to indicate whether each document aut= hor has confirmed that any and all appropriate IPR disclosures required for f= ull conformance with the provisions of BCP 78 and BCP 79 have already been f= iled. >=20 > Could you please confirm? >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-CE715618-4520-4B88-8C95-FDC9123A1A22 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I a= m aware of no IPR. 

Phil

On Sep 19, 2016, at 2:2= 6 AM, Mike Jones <Michael.= Jones@microsoft.com> wrote:

I am aware of no IPR on this specification.
=
               -- Mike

-----Original Message-----
From:= OAuth [mailto:oauth-bounces@ietf.= org] On Behalf Of Hannes Tschofenig
Sent: Monday, Septem= ber 19, 2016 2:21 AM
To: o= auth@ietf.org
Subject: [OAUTH-WG] Authentication Method R= eference Values Document: IPR Confirmation

= Hi Mike, Phil, Tony,


I am w= orking on the shepherd writeup for the AMR document:
https://tool= s.ietf.org/html/draft-ietf-oauth-amr-values-02
One item in the template requires me to indicate whether each docume= nt author has confirmed that any and all appropriate IPR disclosures require= d for full conformance with the provisions of BCP 78 and BCP 79 have already= been filed.

Could you please confirm?

Ciao
Hannes

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

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /blockquote>= --Apple-Mail-CE715618-4520-4B88-8C95-FDC9123A1A22-- From nobody Wed Sep 21 00:59:02 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D812B0F2 for ; Wed, 21 Sep 2016 00:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDOjX4pAag3u for ; Wed, 21 Sep 2016 00:58:58 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0111.outbound.protection.outlook.com [104.47.33.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 1666712B02F for ; Wed, 21 Sep 2016 00:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1337m45qmTvo/LZDHpN6jjdBs2rqz/ewg4arO8+wtxk=; b=Q0865pXWRXgHhjBGqSehTr8WbnMr/MNAFgHiFSPfptABkoI6aL/i31QWZvgqpx0WikWM5DX30cgzqGa5280BMNu4EvLuwhvPTGh9fv5H+QPl0q62UIV2zhf/pdIPhwuZUXM5S9+azJrRuhhhdz+TcXBd2TMayWa+kIlxyKO+qg8= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by BN3PR03MB2356.namprd03.prod.outlook.com (10.166.74.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.599.9; Wed, 21 Sep 2016 07:58:56 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.0629.006; Wed, 21 Sep 2016 07:58:56 +0000 From: Anthony Nadalin To: "Phil Hunt (IDM)" , Mike Jones Thread-Topic: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation Thread-Index: AQHSElf4IZSLHxM100GuC7QDE9JZJqCDUr4AgABEgMA= Date: Wed, 21 Sep 2016 07:58:56 +0000 Message-ID: References: <2fd272fc-4339-c55a-bec0-34e9cc324f5c@gmx.net> <9C98A9AF-69FE-4CFE-8DD0-68B6D0D87BDB@oracle.com> In-Reply-To: <9C98A9AF-69FE-4CFE-8DD0-68B6D0D87BDB@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=tonynad@microsoft.com; x-originating-ip: [62.28.89.233] x-ms-office365-filtering-correlation-id: 94d672f3-c4b1-4a38-65a0-08d3e1f5232f x-microsoft-exchange-diagnostics: 1; BN3PR03MB2356; 6:XbPAwqLGAdBlMoVbYb2/Qz1y/W7h4AcWr43zB6uOYIRmgFn9OvfZe0RHWG4nPQ8R5zKYN4m/DLSuzeIn0megraTzcwZM2qQDAqw04uApl/o6LMWoA6/AvhHzMHASOP19Q8bpNAz7TmU0eBC/0I0zVago/Vmc7VP7xSK30QA0TgrR5g79ZnMEyrj53dRiLqhcHeTbjZiJ52g6+lRLgj6jbCCBAgw/4lsPdUwSe7YmHUkXH3njV3L03XeBKiVrraNTLkcbgmNs3MChXkRhTJr0N6SlsWogHWLeKoR2PvbAOvY5nmg3ecPjTaiuLR23WHNaUrFfWDDSuBCaRDBO7rCBkw==; 5:elPEk1w7Ti8zKC9/tsRRB6mC4NEAuiE6e+ziHmg7jYrf/CaEWNoNsmAs9kqifqJ6OqU6Yd5eDw2TU0EojR0KpkbAqs77wy11UPo7tSQXPJFh8tyJkBCb9JqnpYc1OidS2pF57Esw3otgMjnczAsaEQ==; 24:nnQQkKmFsyqufimPKegOF1PkAVv+no/6zY0JcJ1RYF5h2jQsOpWIXlqW1VeIfN8MAGMNo5Xty5T2rxjixoL7mKYGzwOUvnGta3YJsFCtOKM=; 7:2nea3rLaLE2jXXMuTJpwf3knToMA2f8aCsT9LX4oXjALT3xu05d+ehDJhcziSmWRX6MGUFhtr46USVAoBJwpE1DVGCv7BEINHuDVd3Q5uBOffzZkrgdtvuc7hawdsh1ejELW/jrAV1GXPi8zZCtiYN8apuVMBUwpaNiqLcuIx87P8tmsjyEDrE4JDOgTJrAyuyvvDaPUpDK1gxIRgMw4ft7M82ZV8am1cbRVwXiFgHynX2fnpYNW+w5IUCfuXRu4VmVtEkHuHhqAx6ih88sq5GNdnWgkTmtpINuaChlVt/LxOR4Yx0KCUw/y8JZ4OJ1s x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2356; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB2356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2356; x-forefront-prvs: 007271867D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(24454002)(13464003)(377454003)(19617315012)(790700001)(6116002)(102836003)(2561002)(19625215002)(19609705001)(122556002)(99286002)(3846002)(19580395003)(19580405001)(10090500001)(105586002)(1511001)(106116001)(92566002)(76576001)(189998001)(2421001)(5660300001)(86612001)(5002640100001)(11100500001)(81166006)(6862003)(4326007)(97736004)(76176999)(7846002)(54356999)(106356001)(66066001)(101416001)(33656002)(586003)(2900100001)(86362001)(87936001)(15975445007)(5001770100001)(16236675004)(50986999)(19300405004)(77096005)(2950100001)(10290500002)(8936002)(74316002)(2906002)(8676002)(81156014)(3660700001)(7906003)(7736002)(68736007)(3280700002)(5005710100001)(7696004)(9686002)(10400500002)(8990500004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2356; H:SN1PR0301MB2029.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB2029C545D6209CF38FDB44A8A6F60SN1PR0301MB2029_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2016 07:58:56.0765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2356 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 07:59:01 -0000 --_000_SN1PR0301MB2029C545D6209CF38FDB44A8A6F60SN1PR0301MB2029_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFINCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50IChJRE0pDQpTZW50OiBUdWVz ZGF5LCBTZXB0ZW1iZXIgMjAsIDIwMTYgODo1NCBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMgRG9jdW1lbnQ6 IElQUiBDb25maXJtYXRpb24NCg0KSSBhbSBhd2FyZSBvZiBubyBJUFIuDQoNClBoaWwNCg0KT24g U2VwIDE5LCAyMDE2LCBhdCAyOjI2IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSBh bSBhd2FyZSBvZiBubyBJUFIgb24gdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQogICAgICAgICAgICAg ICAtLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5p Zw0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTksIDIwMTYgMjoyMSBBTQ0KVG86IG9hdXRoQGll dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtPQVVUSC1XR10gQXV0aGVu dGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMgRG9jdW1lbnQ6IElQUiBDb25maXJtYXRp b24NCg0KSGkgTWlrZSwgUGhpbCwgVG9ueSwNCg0KDQpJIGFtIHdvcmtpbmcgb24gdGhlIHNoZXBo ZXJkIHdyaXRldXAgZm9yIHRoZSBBTVIgZG9jdW1lbnQ6DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTAyPGh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5v cmclMmZodG1sJTJmZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTAyJmRhdGE9MDIlN2MwMSU3 Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMzgyZjM3NjU4MDdkNGQ1YWI1NjgwOGQzZTFkNDJm MGMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MTAwMjcz ODgxNDM4MzI3JnNkYXRhPVhXWUpIMVlrUGliUllvaXFFY0t5RWdqRlpiM09VbnZBQ2ZLOXZ3cVdC NDQlM2Q+DQoNCk9uZSBpdGVtIGluIHRoZSB0ZW1wbGF0ZSByZXF1aXJlcyBtZSB0byBpbmRpY2F0 ZSB3aGV0aGVyIGVhY2ggZG9jdW1lbnQgYXV0aG9yIGhhcyBjb25maXJtZWQgdGhhdCBhbnkgYW5k IGFsbCBhcHByb3ByaWF0ZSBJUFIgZGlzY2xvc3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9y bWFuY2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OSBoYXZlIGFscmVh ZHkgYmVlbiBmaWxlZC4NCg0KQ291bGQgeW91IHBsZWFzZSBjb25maXJtPw0KDQpDaWFvDQpIYW5u ZXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5p ZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDIlN2MwMSU3Y3Rvbnlu YWQlNDBtaWNyb3NvZnQuY29tJTdjMzgyZjM3NjU4MDdkNGQ1YWI1NjgwOGQzZTFkNDJmMGMlN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MTAwMjczODgxNDM4 MzI3JnNkYXRhPVB2YXk4dzMzZ2Yzd0lIY09zd2pCTEZUSWtLTTZLc1lYaU1OYThBdDJ1Z28lM2Q+ DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0 Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAyJTdjMDElN2N0b255bmFk JTQwbWljcm9zb2Z0LmNvbSU3YzM4MmYzNzY1ODA3ZDRkNWFiNTY4MDhkM2UxZDQyZjBjJTdjNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjEwMDI3Mzg4MTQzODMy NyZzZGF0YT1QdmF5OHczM2dmM3dJSGNPc3dqQkxGVElrS002S3NZWGlNTmE4QXQydWdvJTNkPg0K --_000_SN1PR0301MB2029C545D6209CF38FDB44A8A6F60SN1PR0301MB2029_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5vdCBhd2FyZSBv ZiBhbnkgSVBSPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+UGhpbCBI dW50IChJRE0pPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIFNlcHRlbWJlciAyMCwgMjAxNiA4 OjU0IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW09BVVRILVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZh bHVlcyBEb2N1bWVudDogSVBSIENvbmZpcm1hdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGF3YXJlIG9mIG5vIElQUi4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBTZXAgMTksIDIwMTYsIGF0IDI6MjYgQU0s IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGF3YXJlIG9m IG5vIElQUiBvbiB0aGlzIHNwZWNpZmljYXRpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tIE1pa2U8YnI+DQo8YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE9BdXRoIFs8YSBocmVmPSJt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWc8YnI+DQpTZW50OiBNb25kYXks IFNlcHRlbWJlciAxOSwgMjAxNiAyOjIxIEFNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzpvYXV0 aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW09BVVRILVdHXSBB dXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlcyBEb2N1bWVudDogSVBSIENvbmZp cm1hdGlvbjxicj4NCjxicj4NCkhpIE1pa2UsIFBoaWwsIFRvbnksPGJyPg0KPGJyPg0KPGJyPg0K SSBhbSB3b3JraW5nIG9uIHRoZSBzaGVwaGVyZCB3cml0ZXVwIGZvciB0aGUgQU1SIGRvY3VtZW50 Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0 Zi1vYXV0aC1hbXItdmFsdWVzLTAyJmFtcDtkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9z b2Z0LmNvbSU3YzM4MmYzNzY1ODA3ZDRkNWFiNTY4MDhkM2UxZDQyZjBjJTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjEwMDI3Mzg4MTQzODMyNyZhbXA7c2Rh dGE9WFdZSkgxWWtQaWJSWW9pcUVjS3lFZ2pGWmIzT1VudkFDZks5dndxV0I0NCUzZCI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlcy0wMjwvYT48 YnI+DQo8YnI+DQpPbmUgaXRlbSBpbiB0aGUgdGVtcGxhdGUgcmVxdWlyZXMgbWUgdG8gaW5kaWNh dGUgd2hldGhlciBlYWNoIGRvY3VtZW50IGF1dGhvciBoYXMgY29uZmlybWVkIHRoYXQgYW55IGFu ZCBhbGwgYXBwcm9wcmlhdGUgSVBSIGRpc2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIGNvbmZv cm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkgaGF2ZSBhbHJl YWR5IGJlZW4gZmlsZWQuPGJyPg0KPGJyPg0KQ291bGQgeW91IHBsZWFzZSBjb25maXJtPzxicj4N Cjxicj4NCkNpYW88YnI+DQpIYW5uZXM8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZh bXA7ZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MzODJmMzc2NTgwN2Q0 ZDVhYjU2ODA4ZDNlMWQ0MmYwYyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj MSU3YzAlN2M2MzYxMDAyNzM4ODE0MzgzMjcmYW1wO3NkYXRhPVB2YXk4dzMzZ2Yzd0lIY09zd2pC TEZUSWtLTTZLc1lYaU1OYThBdDJ1Z28lM2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2Rh dGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMzgyZjM3NjU4MDdkNGQ1YWI1 NjgwOGQzZTFkNDJmMGMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2Mw JTdjNjM2MTAwMjczODgxNDM4MzI3JmFtcDtzZGF0YT1QdmF5OHczM2dmM3dJSGNPc3dqQkxGVElr S002S3NZWGlNTmE4QXQydWdvJTNkIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB2029C545D6209CF38FDB44A8A6F60SN1PR0301MB2029_-- From nobody Mon Sep 26 03:01:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA6712B0F1 for ; Mon, 26 Sep 2016 03:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hdo3766PIuz2 for ; Mon, 26 Sep 2016 03:01:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C855D12B0F0 for ; Mon, 26 Sep 2016 03:01:35 -0700 (PDT) Received: from [192.168.91.133] ([80.92.122.18]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MfjJY-1bcHUW2F4m-00ND0E; Mon, 26 Sep 2016 12:01:32 +0200 To: Nat Sakimura References: <3d39ebb7-29d5-256b-768f-6d97dabd6e23@gmx.net> From: Hannes Tschofenig Message-ID: Date: Mon, 26 Sep 2016 12:01:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Zds7qxd+PFO1WubiB4KdJ1PXYY9PLER+7Vtc7UnuTf5YeveuOuV V9xt7x4cQ1+zlOi1oz7Dh1xfP1G4RF8bWYF5qxxPCzGFpYPqtcHfOEE4d4NbPOFepFE9Ahu sn1G1xNZpubH5XM3q4sUPlldAUjFLkV4LIkGZd+m0nZjm6OLyJ7YglO9Bkuqp/A8c+pDNr/ 2VejoN7alWPDWuRdTcWLg== X-UI-Out-Filterresults: notjunk:1;V01:K0:IRxx+b2/UA0=:UxgemEA1x2klv+8diOpUo5 igwFQrtoFtAMq3P8OpiPNayGpi4zxpObFcYGwcMfqUqUW++hQpoL0bswDy8O1oiKC7CW+szEf wiQZYjd2cpWI/Xm3seTjcmyB+mb8UVQO0xSvg5TRAZ07zEOW8wdwJf0u2L8c6jygaBsc1AKGq ty5L3pi/4AqvAouYFSQaQPnEXgJ3mCVCpZP784T4i/6m0Ej2MkfSG2QyeYZASt4MRMzM14IRq VzwpsdWhKqbxFQIWUc3CnJL206BwAVTNOqBgG5LzYITvtJyF67VlzC2nrFpV6aKEkiQhUsKRt i0MmqexugKFQ3YFDfxjTR9+h4aYEYtxJiq/eWIUfH6MQsX0KwgVDLdouJaVNlzLBZ5p6T+AdE qal36eM7VFdQlQBvMTZ3OFRcy9X1FsJ/DWUWCsKIDcZ10cYW3EiTU+8d/OMfpsYull/4gWNG1 GqQFBF8ZH/WPuyPsJwj9RWC/a9sMxSbsm0Lh/b1eIran572Qr/nQBk8nkNSo268orcpW4u4u/ hR1/53b+PiGzeYiQAYLOXE93kpSQ35+BGY+7DJnYj2tm/9pnEtCnE4Nr2rX/A4vmJHwbuGRTF 6Gan8Zm8HiwGDF0VDRkAompzoILkAmk7C1Rqzd0p/ajd3W3mXY5Efy1zsK5NM8B+ovJFSJPaV R/jjwSjLrMEe0EdkXZqnDlR/oeGPNvBcP/xqNDw0X2SnFmqr5xDIiwMtrvW0JT7DWgmYHgm+F VYAEgLc3O2YkqSniopX7k4zVpw3IqqDOAAS+2oWHR4PG7lqCzCUfBJi0kF4CyVBNFHYfPTFA+ LgX6+AE Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 JWT Authorization Request (JAR): IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 10:01:41 -0000 Hi Nat, I am OK with the newly proposed title. Please submit a new version. Ciao Hannes On 09/19/2016 04:18 PM, Nat Sakimura wrote: > Confirmed. > > BTW, I was waiting for your confirmation about the draft title change as > discussed in the list. > > Shall I just push it? > > > 2016/09/19 午後7:07 "Hannes Tschofenig" >: > > Hi Nat, Hi John, > > I am working on the shepherd writeup for the JAR document: > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08 > > > 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? > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From nobody Mon Sep 26 04:25:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679C012B16C for ; Mon, 26 Sep 2016 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0B8xv2ZdR85 for ; Mon, 26 Sep 2016 04:25:35 -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 12A7A12B15E for ; Mon, 26 Sep 2016 04:25:34 -0700 (PDT) Received: from [192.168.91.133] ([80.92.122.18]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MgGDK-1bd1CN0USM-00NeJr for ; Mon, 26 Sep 2016 13:25:33 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Message-ID: <6b7ba8e3-f4c6-a067-05cc-73e5773cf85c@gmx.net> Date: Mon, 26 Sep 2016 13:25:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:wlbriEVlfZk6iwIZQxH+B9jFYQUA/JpJG9WbgOTN0OlTsPAuw38 GgAMZuE6oPpXbxzPGeY+qebeSJVs9hv1n9EIFgaXJWa5HUGKbBrIAr44jP4V13Kk5qgY4N+ a/yyIwiveHtNhy1AuSOz2AQGW//OJebg0Hxr1kuGXpx6F8hb/tOS55KrspuSBjR4IfxGgPs bwLEtLDVFEPrUTOYhiQCA== X-UI-Out-Filterresults: notjunk:1;V01:K0:SZPfwiatsyA=:oUotqOtfB1o/MwsWqH7OfW CtrjMkivUKzv6AkU8I2fFHA++VHJbmhxa7WFbodV3Ph7HNwR+spaHnsrmQcSYsffpIxjrGwWA 2vPGH8CDbxOGpZWihQJCsCW8riweTBoZXLkzzgzZ41iIgKgs8OJLsLtZPkRVKO5olcNnI6rQp VwpUJ+xyfqvyunX3e8lPb75YWEJ07a31L3PRkGRpqKSNj/7IxTXreYvrHWGpVtrNB4ZKSwGcX AVxBNKA8Ln+lbl2c/3GcCPuLLbKu5mp3sXQFLBTvBLjVrs1nMdAYTmLPrKXuJtg3/0nQMOEgM /l/TXUI38zL7sRv0yHuAUfAS3+yTXWL7wIklkp0RhwJbMzPEb4yk6GSaV4efh6stzL5IOf7Bo HDNyv+JCuwrzeCf/7qXcWHS9g9MFFY1gkkIToVRnOTYQKJoZLCe0MDkvEC6V7UurfQplxHpFN Ay7WF/q2b/sIwZgqUm9LvCsPSs87vJnQFgN12Gx/XaU47O+rbfqWlKGivv5RbwjyWcCKGHIlg ohY2U9Tnv8VxJrUfiygUtZeQcbeHN/eP6/Ej1B5BIjQMebaLFVj+RFDf/invkLm8M/rjFreWn OsTd8QTN5h55GnEjoQyW01kDdkA88rK2RK8qbN1yjGpAPyMpM7fZqWwZz5Y244T05QPU53Cab q7RaPelaISMf395qjkJdapP9/ttAw4vst/TitrnoFbV6u+JsJoJjx2ZBewFRBrLlcFBkkmXSj yxs+onCsvyTroK1adUx+6XnIlGG6fdwQ2V2dwhZczEH+phR31P+0k4FEMsiDiNzwsedsMxxpI 8RLZwZI Archived-At: Subject: [OAUTH-WG] Shepherd Writeup for the OAuth JAR Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 11:25:37 -0000 Hi all, here is the shepherd writeup for the JAR specification: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_JAR.txt Let me know if there are some comments. Nat will also submit a version -09 with minor editorial changes. Ciao Hannes From nobody Mon Sep 26 05:02:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8EC12B191 for ; Mon, 26 Sep 2016 05:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxaor6aEzN_2 for ; Mon, 26 Sep 2016 05:01:55 -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 DEC6812B199 for ; Mon, 26 Sep 2016 05:01:51 -0700 (PDT) Received: from [192.168.91.133] ([80.92.122.18]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lk7T8-1bDlwM3RsY-00c7xf for ; Mon, 26 Sep 2016 14:01:49 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Message-ID: Date: Mon, 26 Sep 2016 14:01:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:13iABB/6pFaWFHkQSeMwKny9eVoGyAkXzw/f2zQZTNwp357KIzw vHfwdpTFBNut0On7O9hrsWbGci0GGPdZ9bx+JJDTqnFwUQl+pEQICMZiaSwwUj4IrVMmKAB bhpJoN4cm0/hBbrGsZKhKJOWkkceolWQioBZNqFMT0DBeLmC3n1gJZl83vmWKNtECWL3Uh1 vNZRf6wTAw2PkZkVb/mAg== X-UI-Out-Filterresults: notjunk:1;V01:K0:M0eUwPYyrNs=:O6CoTIQ74h+IxA24patQm0 HMCsI3wpkUwwuM0UF0AMOb/+ltf1hDvaRkhdfWVZPE/5aKhuGoH8bvekMVJkMG+KO6qlYDf6G 4eCbNwrKfTZbo8F00fpR37INqaLUowLikEO/zo3VbPQIsSCz7mUkjyP6mTCPd/aUYt0jCO+ax y3Mpt9VCxKex/Fel6Z5sehaWiatiaVL5SWF3giVrDvNZRTXHe2TsyZqxJW+EmMg1Gew0ELSM3 UXs3Ad9KKHEVyQvFXd2Truaz5alKLEOnkDVP3kRQOQ1/oSEIcDSHDPiiuQ3M2WFZK9dU4Zka+ dBhRnukPVThnTtoHTSpbpDnziTP2V2cJuUv81AHLQ3oVFGwvXoRlZWkuJINDCUjcGbR8gD3C7 eXuK16jVdxjsmYvX298HzjVG1vLW+orrEmmdqFmKiEgPQPKCPj8UghgZmW5Tju9z7dNE2vcrC osadSGvVndXAAVyTAl/+pwMf0+/kpgWeF9+Qcru9J3ZHtBwinYy21d9qnkWZsbHrcOuJ+VtxV ydQ9UoF1XFiMdRGtFMEOHrl6X6M+ZyegQTzkeRdZUqXTKtHsDfroyG7katVMK1IQxlbiqizxe XmAr24mY96MoZIrqTTeRpanud7inPM9CoZOFRyzVbNOTlIlSUw+EeK+DUOLI481n5Op0Z4TBT tQnpjEGzL5IcQ/bzrnSeukA7GXjq7gvr09nQrc6Api9hXLk76SGibLIRTBxyAT/CWdIpyMGRl jI++bpfb8uLl0618lp447uz7JzfrF1ydYP9V8w/oEp2s04dehVG3mRkePBX+FK2tlkhYleBTk oJTRvx9 Archived-At: Subject: [OAUTH-WG] Shepherd Writeup for OAuth AMR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 12:02:02 -0000 Hi all, Here is the writeup for OAuth AMR: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_AMR.txt There are some questions regarding the normative references. Currently, the list of normative references contains documents that would be clarified as downrefs (since they are informational RFCs). I wonder whether we could make the following references informative: [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, . [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, . [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . [JECM] Williamson, G., "Enhanced Authentication In Online Banking", Journal of Economic Crime Management 4.2: 18-19, 2006, . [MSDN] Microsoft, "Integrated Windows Authentication with Negotiate", September 2011, . [NIST.800-63-2] National Institute of Standards and Technology (NIST), "Electronic Authentication Guideline", NIST Special Publication 800-63-2, August 2013, . Comments on the shepherd writeup are welcome. Ciao Hannes From nobody Mon Sep 26 12:03:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF35E12B2AE for ; Mon, 26 Sep 2016 12:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5HVtrAko8n6 for ; Mon, 26 Sep 2016 12:03:42 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0110.outbound.protection.outlook.com [104.47.34.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5899B12B36B for ; Mon, 26 Sep 2016 12:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VQMVQbgoqmc5Y45xnXUQ+s7Cs6v+oSVXwwLb68k4zjw=; b=TUAmf60+/diNgfqo3XmH9GqlVQvMg5Yci3GAttmn6U+Dhfeow3XyTP1IwfkxjuY9ULm3AHlf5IKRsJ7mJDZbrWyOOMxTcgt5sWmsN3W1cnE6Le2oexRuxIMNeevHxMVocyu3fqkA/0KEbxiIf33jf7vPzsmWuwNXrqcwLAHTuxU= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2356.namprd03.prod.outlook.com (10.166.74.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Mon, 26 Sep 2016 19:02:21 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0639.011; Mon, 26 Sep 2016 19:02:21 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Shepherd Writeup for OAuth AMR Thread-Index: AQHSF+3PDWT304zcpEGBiCU6qqZ8oKCMISeO Date: Mon, 26 Sep 2016 19:02:20 +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: [107.77.210.50] x-ms-office365-filtering-correlation-id: baa6f325-9283-4c8d-67e3-08d3e63fa4c1 x-microsoft-exchange-diagnostics: 1; BN3PR03MB2356; 6:TBII6/oZzC+fYHawgjbTWvAhs2/rgjxPc37PNYryyuPfZDfLlsKb9DM7siAu9SmeI9wvjMI/PvpjX1xFSa1WTvEOCqIGhfu9SyEKc5TWohTpUVdlcUft+2NWNFlF5JUsxcn+e4GG5gpEjaH2Dstj7ic6PcwuqgZVqn2NDx19oSxmCYcJ9Nabez1z336KsdSYbLcK7yJQdTEGaJ4FzMWqzyuG4xf8eMQmx6Re3qpS1koMWB3KayIjJpcez4gHi2Ekm2eMm4toHcwynG9bqeU6FEhkN1HAZKfiLWHhQWhRk5SVOittJKXmIfCu9Nf7q6z0aY17ynEXYEK+saclEBbWSA==; 5:almH1hACkEYmzmOoNKXhYZ+wjsVBXsJj6j8Fb8UhbFnS6s/8MhkfHwDlNZ024FWktEmQnesP6AGMi7gTYlhRHnT1nOI7DyicBzklUanrCqNuiWzpE9GyKcwEzMDYmMn9z0lvSyk7Kyx/wgJZ6SEbzQ==; 24:Jn3Mtu7vTXISok+edbJKOQtAbapm7wWhc2gZSa45Gp/J9tlgKBiKqBjdW+Ix5htOkJcoeYZ9xlndlwYx80WE+tfeajf5qOGQ4lJNUj8EJVI=; 7:pAy8XE1Hz6pqa0gChmPOn1Fg0cTx8I2qsyM70L3AHnSHh1hk7fr6dc4WsUMkCpymB3q6QHkW8+/yOEYAyeKXAufiHPuMj62YV3N1SozAq9UADtmri3Alt2jDPzho+JBiMcBh9w4KJl+8m7X9q3osmQda8COSlqggNdP0XNppJgqhz3UjK0JAFCtn6YvQDLXjQnPsxlHRmOiVprcvvb5Lmrs3UqAESYgTrgSeU2QRvgXbzHh33MKEfl7Ni+vxGHYInRZJwMhQfMvfc1YkyusTnR+GTHvR5tk72LfG4oXAhZhI2eZb1tRvmLInXf30tqGD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2356; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(166708455590820)(209352067349851)(248736688235697)(194585677185034); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB2356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2356; x-forefront-prvs: 00770C4423 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(53754006)(68736007)(107886002)(7846002)(7736002)(76576001)(2501003)(19625215002)(74316002)(81166006)(3846002)(5005710100001)(102836003)(10400500002)(6116002)(10290500002)(5660300001)(551544002)(9686002)(92566002)(189998001)(2906002)(7906003)(5001770100001)(8990500004)(97736004)(8676002)(10090500001)(81156014)(122556002)(586003)(19617315012)(87936001)(7696004)(15395725005)(101416001)(99286002)(77096005)(8936002)(11100500001)(2900100001)(19580405001)(19580395003)(16236675004)(15975445007)(2950100002)(50986999)(76176999)(54356999)(3660700001)(5002640100001)(86362001)(66066001)(33656002)(86612001)(3900700001)(3280700002)(105586002)(106116001)(106356001)(18265965002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2356; H:BN3PR03MB2355.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB235594317529C01BE76547DDF5CD0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2016 19:02:20.8066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2356 Archived-At: Subject: Re: [OAUTH-WG] Shepherd Writeup for OAuth AMR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 19:03:45 -0000 --_000_BN3PR03MB235594317529C01BE76547DDF5CD0BN3PR03MB2355namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, Hannes. I=92ll plan to make these changes once I=92m back in circul= ation =96 probably early next week. =96 Mike From: Hannes Tschofenig Sent: Monday, September 26, 2016 7:02 AM To: oauth@ietf.org Subject: [OAUTH-WG] Shepherd Writeup for OAuth AMR Hi all, Here is the writeup for OAuth AMR: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-wri= teups/Writeup_OAuth_AMR.txt There are some questions regarding the normative references. Currently, the list of normative references contains documents that would be clarified as downrefs (since they are informational RFCs). I wonder whether we could make the following references informative: [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, . [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, . [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . [JECM] Williamson, G., "Enhanced Authentication In Online Banking", Journal of Economic Crime Management 4.2: 18-19, 2006, . [MSDN] Microsoft, "Integrated Windows Authentication with Negotiate", September 2011, . [NIST.800-63-2] National Institute of Standards and Technology (NIST), "Electronic Authentication Guideline", NIST Special Publication 800-63-2, August 2013, . Comments on the shepherd writeup are welcome. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BN3PR03MB235594317529C01BE76547DDF5CD0BN3PR03MB2355namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks, Hannes. I=92ll plan to make these changes = once I=92m back in circulation =96 probably early next week.

 

=96 Mike

 

 

From: Hannes Tschofenig
Sent: Monday, September 26, 2016 7:02 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Shepherd Writeup for OAuth AMR

 

Hi all,

Here is the writeup for OAuth AMR:
https://github.com/hannestschofenig= /tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_AMR.txt

There are some questions regarding the normative references. Currently, the list of normative references contains documents that would be
clarified as downrefs (since they are informational RFCs).

I wonder whether we could make the following references informative:

    [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F.,= Naccache, D., and
            &nb= sp;  O. Ranen, "HOTP: An HMAC-Based One-Time Password
            &nb= sp;  Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005,             &nb= sp;  <http://www= .rfc-editor.org/info/rfc4226>.


    [RFC6238]  M'Raihi, D., Machani, S., Pei, M., and J= . Rydell, "TOTP:
            &nb= sp;  Time-Based One-Time Password Algorithm", RFC 6238,
            &nb= sp;  DOI 10.17487/RFC6238, May 2011,
            &nb= sp;  <http://www= .rfc-editor.org/info/rfc6238>.

    [RFC4211]  Schaad, J., "Internet X.509 Public = Key Infrastructure
            &nb= sp;  Certificate Request Message Format (CRMF)", RFC 4211,
            &nb= sp;  DOI 10.17487/RFC4211, September 2005,
            &nb= sp;  <http://www= .rfc-editor.org/info/rfc4211>.

    [JECM]     Williamson, G., "Enh= anced Authentication In Online
            &nb= sp;  Banking", Journal of Economic Crime Management 4.2: 18-19,             &nb= sp;  2006,
            &nb= sp;  <http://utica.edu/academic/institutes/ecii/pu= blications/
            &nb= sp;  articles/51D6D996-90F2-F468-AC09C4E8071575AE.pdf>.

    [MSDN]     Microsoft, "Integrat= ed Windows Authentication with
            &nb= sp;  Negotiate", September 2011,
            &nb= sp;  <http://blogs.msdn.com/b/benjaminperkins/
            &nb= sp;  archive/2011/09/14/iis-integrated-windows-authentication-
            &nb= sp;  with-negotiate.aspx>.

    [NIST.800-63-2]
            &nb= sp;  National Institute of Standards and Technology (NIST),
            &nb= sp;  "Electronic Authentication Guideline", NIST Special
            &nb= sp;  Publication 800-63-2, August 2013,
            &nb= sp;  <http://nvlpubs.nist.gov/nistpubs/SpecialPubl= ications/
            &nb= sp;  NIST.SP.800-63-2.pdf>.

Comments on the shepherd writeup are welcome.

Ciao
Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth
 --_000_BN3PR03MB235594317529C01BE76547DDF5CD0BN3PR03MB2355namp_-- From nobody Tue Sep 27 07:02:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DF212B1DE for ; Tue, 27 Sep 2016 07:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mfCsCykpDwa for ; Tue, 27 Sep 2016 07:02:44 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159DF12B1D6 for ; Tue, 27 Sep 2016 07:02:44 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id n13so11431577uaa.3 for ; Tue, 27 Sep 2016 07:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oTRQ2igThRiZOLMEOLKXPIE/VleVY/Fiyw8GJIunt1s=; b=Nl6L0YaM8vJD5EcUG6LbkT8VtvEMbWrLwodDtGSNp+HQyifS97HbG2IUWX35IQZCJA wTFGgabeYaHbS4pVk3jlhC5mnDaJcRFt6zlZNY1OEC0nw8qq59hsxwG0HGUhinEJ/NYK n15C47Qn5nLZeTIkO4fvSMJ94RY+0lDwDPR15716I8tZgacxBv+1B1hms0s+I98bVpdi UJ8PNE0/rS8z4a1hvKlbmAIIWR2jYmDklRpVP4Ja4FEbh+B4VCkZzGIzdDaJDOJnbtXr 25Fsn29oTRMAiAedZeMBJZNYsc926fOR8YjuIN4sEFrfExcr2NtO0m+xEsNY00ZKgxJR ZvdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oTRQ2igThRiZOLMEOLKXPIE/VleVY/Fiyw8GJIunt1s=; b=hXGEFX1dXbeqo0gCaes9/lrkUUYeZe27vKF1d6rzY7yYNd378ipRj0A55lcbuI9apX 6jqOgziXEvzXfLQmt3WnnlQJ/IvrZz94fdjObKRB2F+/Epao9waau0oc9c5XhVJWrw23 S9Q8Ch42PB5fhVaI7wyqzINLdXDOpLY3bDIDo8e4MI+kCF5iEJhQm8iR8EZQSaWtkoa3 yb45LvGLVUlLChlAMDo51k+M1KVz/PvQdo1BFX85iZ4ID0MFt2JGqGrqpKZY3s5m8Y/N KyaXzmdw8ydGd1A5it5/VnRWBhi4gAj7ONZVp78klcme9LmTeCtdNgsWizoB7KN4Cp4o 9efA== X-Gm-Message-State: AA6/9RmJ+ijfZl9eloKcij/81g1qzSD9E14MI44RnKi8eE8VBrdK7h5k+O+R9WX4hrmGB5WrodFZOeH2lDq5tg== X-Received: by 10.176.82.109 with SMTP id j42mr2437459uaa.170.1474984963148; Tue, 27 Sep 2016 07:02:43 -0700 (PDT) MIME-Version: 1.0 References: <831693C2CDA2E849A7D7A712B24E257F4A4773F3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <1cae674a-853d-84ae-b7d2-ae63c0eff425@mit.edu> <831693C2CDA2E849A7D7A712B24E257F4A4774AA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A4774AA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: Nat Sakimura Date: Tue, 27 Sep 2016 14:02:32 +0000 Message-ID: To: "Hollenbeck, Scott" , Justin Richer , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c190200c7111c053d7db268 Archived-At: Subject: Re: [OAUTH-WG] Identity Provider Interop Testing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 14:02:48 -0000 --94eb2c190200c7111c053d7db268 Content-Type: text/plain; charset=UTF-8 There is an interop list which does not have IPR requirement. The IPR Contribution Agreement is there to prevent a party to embed patent encumbered claims into the specification to collect license fees at a later date. There is no need for such in just working with the interops. OpenID Connect Interop Group: https://groups.google.com/forum/#!forum/openid-connect-interop Cheers, Nat On Mon, Sep 19, 2016 at 11:37 PM Hollenbeck, Scott wrote: > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > > Sent: Monday, September 19, 2016 9:35 AM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Identity Provider Interop Testing? > > > > You're better off contacting the OpenID Connect working group and the > > interoperability list there. > > > > http://openid.net/wg/connect/ > > > > While there's a lot of overlap in the communities, OAuth and OIDC are > > different protocols and the discussion you want is better held there. > > Understood, but there's this little detail: > > > Please note that while anyone can join the mailing list as a read-only > > recipient, posting to the mailing list or actively contributing to the > > specification itself requires the submission of an IPR Agreement. > > Sorry for the off-topic post, but I thought that a note sent to this list > might just find the right people without having to deal with the overhead > of getting an IPR Agreement in place to gain posting privileges. > > Scott > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation --94eb2c190200c7111c053d7db268 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is an interop list which does not have IPR requireme= nt.=C2=A0
The IPR Contribution Agreement is there to prevent a party to= embed patent encumbered claims into the specification to collect license f= ees at a later date. There is no need for such in just working with the int= erops.=C2=A0

OpenID Connect Interop Group:=C2=A0ht= tps://groups.google.com/forum/#!forum/openid-connect-interop
=
Cheers,=C2=A0

Nat

On Mon, Sep 19, 2016 at 11:37 PM = Hollenbeck, Scott <shollenbe= ck@verisign.com> wrote:
>= -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
> Sent: Monday, September 19, 2016 9:35 AM
> To: oauth@ietf.org=
> Subject: Re: [OAUTH-WG] Identity Provider Interop Testing?
>
> You're better off contacting the OpenID Connect working group and = the
> interoperability list there.
>
> http://openid.net/wg/connect/
>
> While there's a lot of overlap in the communities, OAuth and OIDC = are
> different protocols and the discussion you want is better held there.<= br>
Understood, but there's this little detail:

> Please note that while anyone can join the mailing list as a read-only=
> recipient, posting to the mailing list or actively contributing to the=
> specification itself requires the submission of an IPR Agreement.

Sorry for the off-topic post, but I thought that a note sent to this list m= ight just find the right people without having to deal with the overhead of= getting an IPR Agreement in place to gain posting privileges.

Scott

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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c190200c7111c053d7db268-- From nobody Tue Sep 27 07:23:04 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A636212B134 for ; Tue, 27 Sep 2016 07:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfQBhYtLOGgW for ; Tue, 27 Sep 2016 07:22:58 -0700 (PDT) Received: from mail-qt0-x264.google.com (mail-qt0-x264.google.com [IPv6:2607:f8b0:400d:c0d::264]) (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 B797712B209 for ; Tue, 27 Sep 2016 07:22:57 -0700 (PDT) Received: by mail-qt0-x264.google.com with SMTP id z36so52987qtc.0 for ; Tue, 27 Sep 2016 07:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=6chGJ8JVCxfWLjUly/Ijt4GO7w/IE7eegwec4ItkPMY=; b=UKrfkCT3zNCPcnp9ewAqfbRV6P0jFvGN9XnEsKDLmKPl95GfwCbstYlEZ9K32Oiq/D SEfdwPST255qywhP6Y2s/xcg8+u3+hsOahA4oOZjb3Av+8n1MJz7yf1JG6OA+Nmk5/VX H2Brhj8CwfbpIYqFadWjnhQKxr2/xpr7X0rsvHob3m98glr+XFT9sO1t2PfoGSSg7NLW ypeL5x5MJAAmnI0DCu6cwj1Na3xVAw/sKq/Qy4PhRZSFRLRELXg+AMrB8vJkcicwPLE9 LKtt+PNmGUD6s9ee8gQucwId0C/cR8+NF+uWrZxnaozlPtKaAmPcln3n+789meQ3cWi4 Dwqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=6chGJ8JVCxfWLjUly/Ijt4GO7w/IE7eegwec4ItkPMY=; b=JReHKN0UDlD9fjFzOHdMmXgdXduN+RaVpo1C3kOz4ywAy1rXbeKM+3dGQf8Qgd6Boz MXvfiQdrllR3n3KSx0A/NMky7DNYYz1gI+uZHWe75YHUDSGh3B4ZuQC9ZAenldnMSFRf cXpfNLsXEvz/MI7e9km9tCgcPFbqIz+GuBKym8kyLXKEIU484UEfM91AOJe02f6iPZEo d8cQTaWIGLTYhdAFfMyl8ohiTwb1niTno/RPWIpmuXDndzdsDb4zicq1E6zWyfk2KwpF flW8PgvXBOVVfWuTlg8Mh4GsXZEdHL5UMWwHv0ZVFF3aw+ET+zHNbpno/11l/VMnx7Jr iihQ== X-Gm-Message-State: AA6/9Rlgo6rYqBNpWQLt0qiDoZC7BJXRGUqc/+p20Evl1NJ/IXu7O8wOT9ft8b3NTeDXrCRVbHvnwbYHOGu/ID9OiWCeZYZm X-Received: by 10.55.147.66 with SMTP id v63mr26346578qkd.298.1474986176764; Tue, 27 Sep 2016 07:22:56 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id v198sm209452qka.6.2016.09.27.07.22.56 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 27 Sep 2016 07:22:56 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u8REMuCa022363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Sep 2016 10:22:56 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 10:22:54 -0400 From: "Hollenbeck, Scott" To: Nat Sakimura , Justin Richer , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Identity Provider Interop Testing? Thread-Index: AQHSGMfSzF+fhohsvkmm3EWb3tckSaCNY5fw Date: Tue, 27 Sep 2016 14:22:53 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A48B1AA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A4773F3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <1cae674a-853d-84ae-b7d2-ae63c0eff425@mit.edu> <831693C2CDA2E849A7D7A712B24E257F4A4774AA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4A48B1AABRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Identity Provider Interop Testing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 14:23:02 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4A48B1AABRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBOYXQuDQoNClNjb3R0DQoNCkZyb206IE5hdCBTYWtpbXVyYSBbbWFpbHRvOnNha2lt dXJhQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNywgMjAxNiAxMDowMyBB TQ0KVG86IEhvbGxlbmJlY2ssIFNjb3R0OyBKdXN0aW4gUmljaGVyOyBvYXV0aEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gSWRlbnRpdHkgUHJvdmlkZXIgSW50ZXJvcCBUZXN0aW5n Pw0KDQpUaGVyZSBpcyBhbiBpbnRlcm9wIGxpc3Qgd2hpY2ggZG9lcyBub3QgaGF2ZSBJUFIgcmVx dWlyZW1lbnQuDQpUaGUgSVBSIENvbnRyaWJ1dGlvbiBBZ3JlZW1lbnQgaXMgdGhlcmUgdG8gcHJl dmVudCBhIHBhcnR5IHRvIGVtYmVkIHBhdGVudCBlbmN1bWJlcmVkIGNsYWltcyBpbnRvIHRoZSBz cGVjaWZpY2F0aW9uIHRvIGNvbGxlY3QgbGljZW5zZSBmZWVzIGF0IGEgbGF0ZXIgZGF0ZS4gVGhl cmUgaXMgbm8gbmVlZCBmb3Igc3VjaCBpbiBqdXN0IHdvcmtpbmcgd2l0aCB0aGUgaW50ZXJvcHMu DQoNCk9wZW5JRCBDb25uZWN0IEludGVyb3AgR3JvdXA6IGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5j b20vZm9ydW0vIyFmb3J1bS9vcGVuaWQtY29ubmVjdC1pbnRlcm9wDQoNCkNoZWVycywNCg0KTmF0 DQoNCk9uIE1vbiwgU2VwIDE5LCAyMDE2IGF0IDExOjM3IFBNIEhvbGxlbmJlY2ssIFNjb3R0IDxz aG9sbGVuYmVja0B2ZXJpc2lnbi5jb208bWFpbHRvOnNob2xsZW5iZWNrQHZlcmlzaWduLmNvbT4+ IHdyb3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPQXV0aCBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgSnVzdGluIFJpY2hlcg0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAx OSwgMjAxNiA5OjM1IEFNDQo+IFRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+DQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIElkZW50aXR5IFByb3ZpZGVyIEludGVyb3Ag VGVzdGluZz8NCj4NCj4gWW91J3JlIGJldHRlciBvZmYgY29udGFjdGluZyB0aGUgT3BlbklEIENv bm5lY3Qgd29ya2luZyBncm91cCBhbmQgdGhlDQo+IGludGVyb3BlcmFiaWxpdHkgbGlzdCB0aGVy ZS4NCj4NCj4gaHR0cDovL29wZW5pZC5uZXQvd2cvY29ubmVjdC8NCj4NCj4gV2hpbGUgdGhlcmUn cyBhIGxvdCBvZiBvdmVybGFwIGluIHRoZSBjb21tdW5pdGllcywgT0F1dGggYW5kIE9JREMgYXJl DQo+IGRpZmZlcmVudCBwcm90b2NvbHMgYW5kIHRoZSBkaXNjdXNzaW9uIHlvdSB3YW50IGlzIGJl dHRlciBoZWxkIHRoZXJlLg0KDQpVbmRlcnN0b29kLCBidXQgdGhlcmUncyB0aGlzIGxpdHRsZSBk ZXRhaWw6DQoNCj4gUGxlYXNlIG5vdGUgdGhhdCB3aGlsZSBhbnlvbmUgY2FuIGpvaW4gdGhlIG1h aWxpbmcgbGlzdCBhcyBhIHJlYWQtb25seQ0KPiByZWNpcGllbnQsIHBvc3RpbmcgdG8gdGhlIG1h aWxpbmcgbGlzdCBvciBhY3RpdmVseSBjb250cmlidXRpbmcgdG8gdGhlDQo+IHNwZWNpZmljYXRp b24gaXRzZWxmIHJlcXVpcmVzIHRoZSBzdWJtaXNzaW9uIG9mIGFuIElQUiBBZ3JlZW1lbnQuDQoN ClNvcnJ5IGZvciB0aGUgb2ZmLXRvcGljIHBvc3QsIGJ1dCBJIHRob3VnaHQgdGhhdCBhIG5vdGUg c2VudCB0byB0aGlzIGxpc3QgbWlnaHQganVzdCBmaW5kIHRoZSByaWdodCBwZW9wbGUgd2l0aG91 dCBoYXZpbmcgdG8gZGVhbCB3aXRoIHRoZSBvdmVyaGVhZCBvZiBnZXR0aW5nIGFuIElQUiBBZ3Jl ZW1lbnQgaW4gcGxhY2UgdG8gZ2FpbiBwb3N0aW5nIHByaXZpbGVnZXMuDQoNClNjb3R0DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCi0tDQoNCk5hdCBTYWtpbXVyYQ0K DQpDaGFpcm1hbiBvZiB0aGUgQm9hcmQsIE9wZW5JRCBGb3VuZGF0aW9uDQo= --_000_831693C2CDA2E849A7D7A712B24E257F4A48B1AABRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpu b3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCBOYXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2NvdHQ8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5hdCBTYWtpbXVyYSBb bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBT ZXB0ZW1iZXIgMjcsIDIwMTYgMTA6MDMgQU08YnI+DQo8Yj5Ubzo8L2I+IEhvbGxlbmJlY2ssIFNj b3R0OyBKdXN0aW4gUmljaGVyOyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW09BVVRILVdHXSBJZGVudGl0eSBQcm92aWRlciBJbnRlcm9wIFRlc3Rpbmc/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGFu IGludGVyb3AgbGlzdCB3aGljaCBkb2VzIG5vdCBoYXZlIElQUiByZXF1aXJlbWVudC4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgSVBSIENvbnRy aWJ1dGlvbiBBZ3JlZW1lbnQgaXMgdGhlcmUgdG8gcHJldmVudCBhIHBhcnR5IHRvIGVtYmVkIHBh dGVudCBlbmN1bWJlcmVkIGNsYWltcyBpbnRvIHRoZSBzcGVjaWZpY2F0aW9uIHRvIGNvbGxlY3Qg bGljZW5zZSBmZWVzIGF0IGEgbGF0ZXIgZGF0ZS4gVGhlcmUgaXMgbm8gbmVlZCBmb3Igc3VjaCBp biBqdXN0IHdvcmtpbmcgd2l0aCB0aGUgaW50ZXJvcHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9wZW5JRCBDb25uZWN0IEludGVy b3AgR3JvdXA6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9mb3J1bS8j IWZvcnVtL29wZW5pZC1jb25uZWN0LWludGVyb3AiPmh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20v Zm9ydW0vIyFmb3J1bS9vcGVuaWQtY29ubmVjdC1pbnRlcm9wPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24s IFNlcCAxOSwgMjAxNiBhdCAxMTozNyBQTSBIb2xsZW5iZWNrLCBTY290dCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNob2xsZW5iZWNrQHZlcmlzaWduLmNvbSI+c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0 OyBGcm9tOiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFs ZiBPZiBKdXN0aW4gUmljaGVyPGJyPg0KJmd0OyBTZW50OiBNb25kYXksIFNlcHRlbWJlciAxOSwg MjAxNiA5OjM1IEFNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBJZGVudGl0eSBQcm92aWRlciBJbnRlcm9wIFRlc3Rpbmc/PGJyPg0KJmd0 Ozxicj4NCiZndDsgWW91J3JlIGJldHRlciBvZmYgY29udGFjdGluZyB0aGUgT3BlbklEIENvbm5l Y3Qgd29ya2luZyBncm91cCBhbmQgdGhlPGJyPg0KJmd0OyBpbnRlcm9wZXJhYmlsaXR5IGxpc3Qg dGhlcmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvd2cv Y29ubmVjdC8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0Lzwv YT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGlsZSB0aGVyZSdzIGEgbG90IG9mIG92ZXJsYXAgaW4g dGhlIGNvbW11bml0aWVzLCBPQXV0aCBhbmQgT0lEQyBhcmU8YnI+DQomZ3Q7IGRpZmZlcmVudCBw cm90b2NvbHMgYW5kIHRoZSBkaXNjdXNzaW9uIHlvdSB3YW50IGlzIGJldHRlciBoZWxkIHRoZXJl Ljxicj4NCjxicj4NClVuZGVyc3Rvb2QsIGJ1dCB0aGVyZSdzIHRoaXMgbGl0dGxlIGRldGFpbDo8 YnI+DQo8YnI+DQomZ3Q7IFBsZWFzZSBub3RlIHRoYXQgd2hpbGUgYW55b25lIGNhbiBqb2luIHRo ZSBtYWlsaW5nIGxpc3QgYXMgYSByZWFkLW9ubHk8YnI+DQomZ3Q7IHJlY2lwaWVudCwgcG9zdGlu ZyB0byB0aGUgbWFpbGluZyBsaXN0IG9yIGFjdGl2ZWx5IGNvbnRyaWJ1dGluZyB0byB0aGU8YnI+ DQomZ3Q7IHNwZWNpZmljYXRpb24gaXRzZWxmIHJlcXVpcmVzIHRoZSBzdWJtaXNzaW9uIG9mIGFu IElQUiBBZ3JlZW1lbnQuPGJyPg0KPGJyPg0KU29ycnkgZm9yIHRoZSBvZmYtdG9waWMgcG9zdCwg YnV0IEkgdGhvdWdodCB0aGF0IGEgbm90ZSBzZW50IHRvIHRoaXMgbGlzdCBtaWdodCBqdXN0IGZp bmQgdGhlIHJpZ2h0IHBlb3BsZSB3aXRob3V0IGhhdmluZyB0byBkZWFsIHdpdGggdGhlIG92ZXJo ZWFkIG9mIGdldHRpbmcgYW4gSVBSIEFncmVlbWVudCBpbiBwbGFjZSB0byBnYWluIHBvc3Rpbmcg cHJpdmlsZWdlcy48YnI+DQo8YnI+DQpTY290dDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwPk5hdCBTYWtpbXVyYTxvOnA+PC9vOnA+PC9wPg0KPHA+Q2hhaXJtYW4gb2Yg dGhlIEJvYXJkLCBPcGVuSUQgRm91bmRhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_831693C2CDA2E849A7D7A712B24E257F4A48B1AABRN1WNEXMBX01vc_-- From nobody Tue Sep 27 07:28:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5302C12B1EE for ; Tue, 27 Sep 2016 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH1Vj66WOyPn for ; Tue, 27 Sep 2016 07:28:21 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB7212B1E5 for ; Tue, 27 Sep 2016 07:28:20 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id n13so12160004uaa.3 for ; Tue, 27 Sep 2016 07:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=j+JljVz/ymhedCeQntl6UEX7aShJgVCTwnKyv3TOweM=; b=WsuN5/oV1StBXM3C6KzqhYItZtTcKtzf6qZWbuclioh8quon5UTUDhU7BzrPAKobs+ UWNr0H08RJKrxwJAhirPnyuPLbaihT60BHTjrmGZDHhpUlsCCo2uhyWdQi1zBqa9FiRw RG9Vyn+QDmmUPUjsCEL2Y6+wXDWd3bN0Z3hc7JlJ06jrUkcivUJUh5SaXlvEyCRJtToE wWLZYHXQAjdMSItLJOA6JtGfjkjplFvQoyGAylz+ALfa+0AU86TcU7k6Ki4+k3ZbiAmO DNuNZ2BxNuo++XHKi57wRIg3vZW3YU/ifZWV3FkEHOk1I3dKQcdVqi3ixuGL/clS7IuB 2s8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=j+JljVz/ymhedCeQntl6UEX7aShJgVCTwnKyv3TOweM=; b=BMKLiLHKQBKI8K6rnSqa02lGaEl++5bYpbwUpZ10YZY6xFFeDsAjlSPoSAJE52YhVl /X+1EYu78EsGNDnprnHS4IYVY2MbzEaVIEG6uDw8NiOqbgwS6l4iX/+49vT16ee+8G9r 9BB30JAWPMZAHsS4X1ctg9bgGeSde2VVOZWNKku1wZ/4XwTDDoD9ANOU2W/KAiIsxKQY pJ/dta0lcUB21TGiTJZC3ET9u4AgLfklhMpWUmNoLjiipZrJg0BmotXPDn0Fzcpt20Li tsXSYbemjppUN/BevazLdVcx2ReDlkv8AXUn+hy2zHS9Mo+t+vWABkG7g+OwnffTp29K AZnQ== X-Gm-Message-State: AA6/9Rn+BKG5tf97pZvCEN6oruOqsG4jWAjZNYKZSUCrBpS3Sh8W1Y+Wls55hC1df+kmMqQg5P9/jknzdBU+5w== X-Received: by 10.176.82.109 with SMTP id j42mr2582043uaa.170.1474986498920; Tue, 27 Sep 2016 07:28:18 -0700 (PDT) MIME-Version: 1.0 References: <831693C2CDA2E849A7D7A712B24E257F4A4773F3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <1cae674a-853d-84ae-b7d2-ae63c0eff425@mit.edu> <831693C2CDA2E849A7D7A712B24E257F4A4774AA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4A48B1AA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A48B1AA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: Nat Sakimura Date: Tue, 27 Sep 2016 14:28:07 +0000 Message-ID: To: "Hollenbeck, Scott" , Justin Richer , "oauth@ietf.org" , Mike Jones Content-Type: multipart/alternative; boundary=94eb2c190200515223053d7e0e4f Archived-At: Subject: Re: [OAUTH-WG] Identity Provider Interop Testing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 14:28:23 -0000 --94eb2c190200515223053d7e0e4f Content-Type: text/plain; charset=UTF-8 Just as a side note: we are constructing the RP testing suite right now. Perhaps you might want to become a beta tester as well. For more info, please contact Mike Jones, who is CC'ed, for the detail. Best, Nat On Tue, Sep 27, 2016 at 11:22 PM Hollenbeck, Scott wrote: > Thanks, Nat. > > > > Scott > > > > *From:* Nat Sakimura [mailto:sakimura@gmail.com] > *Sent:* Tuesday, September 27, 2016 10:03 AM > *To:* Hollenbeck, Scott; Justin Richer; oauth@ietf.org > > > *Subject:* Re: [OAUTH-WG] Identity Provider Interop Testing? > > > > There is an interop list which does not have IPR requirement. > > The IPR Contribution Agreement is there to prevent a party to embed patent > encumbered claims into the specification to collect license fees at a later > date. There is no need for such in just working with the interops. > > > > OpenID Connect Interop Group: > https://groups.google.com/forum/#!forum/openid-connect-interop > > > > Cheers, > > > > Nat > > > > On Mon, Sep 19, 2016 at 11:37 PM Hollenbeck, Scott < > shollenbeck@verisign.com> wrote: > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > > Sent: Monday, September 19, 2016 9:35 AM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Identity Provider Interop Testing? > > > > You're better off contacting the OpenID Connect working group and the > > interoperability list there. > > > > http://openid.net/wg/connect/ > > > > While there's a lot of overlap in the communities, OAuth and OIDC are > > different protocols and the discussion you want is better held there. > > Understood, but there's this little detail: > > > Please note that while anyone can join the mailing list as a read-only > > recipient, posting to the mailing list or actively contributing to the > > specification itself requires the submission of an IPR Agreement. > > Sorry for the off-topic post, but I thought that a note sent to this list > might just find the right people without having to deal with the overhead > of getting an IPR Agreement in place to gain posting privileges. > > Scott > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > -- Nat Sakimura Chairman of the Board, OpenID Foundation --94eb2c190200515223053d7e0e4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just as a side note: we are constructing the RP testing su= ite right now. Perhaps you might want to become a beta tester as well. For = more info, please contact Mike Jones, who is CC'ed, for the detail.=C2= =A0

Best,=C2=A0

Nat

On Tue, Sep 27, 2016 at 11:22 PM = Hollenbeck, Scott <shollenbe= ck@verisign.com> wrote:

Thanks, Nat.

=C2=A0

Scott<= u>

=C2=A0

From: Nat Saki= mura [mailto:sakimu= ra@gmail.com]
Sent: Tuesday, September 27, 2016 10:03 AM
To: Hollenbeck, Scott; Justin Richer; oauth@ietf.org

=
<= div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0= in 0in">


Subject: Re: [OAUTH-WG] Identity Provider Interop Testing?=

=C2=A0

There is an interop list which does not have IPR req= uirement.=C2=A0

The IPR Contribution Agreement is there to prevent a= party to embed patent encumbered claims into the specification to collect = license fees at a later date. There is no need for such in just working wit= h the interops.=C2=A0

=C2=A0

OpenID Connect Interop Group:=C2=A0https://groups.google.com/forum/#!forum/openid-connect-interop<= u>

=C2=A0

Cheers,=C2=A0

=C2=A0

Nat

=C2=A0

On Mon, Sep 19, 2016 at 11:37 PM Hollenbeck, Scott &= lt;shollenbec= k@verisign.com> wrote:

> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
> Sent: Monday, September 19, 2016 9:35 AM
> To: oauth@ietf.org=
> Subject: Re: [OAUTH-WG] Identity Provider Interop Testing?
>
> You're better off contacting the OpenID Connect working group and = the
> interoperability list there.
>
> http://ope= nid.net/wg/connect/
>
> While there's a lot of overlap in the communities, OAuth and OIDC = are
> different protocols and the discussion you want is better held there.<= br>
Understood, but there's this little detail:

> Please note that while anyone can join the mailing list as a read-only=
> recipient, posting to the mailing list or actively contributing to the=
> specification itself requires the submission of an IPR Agreement.

Sorry for the off-topic post, but I thought that a note sent to this list m= ight just find the right people without having to deal with the overhead of= getting an IPR Agreement in place to gain posting privileges.

Scott

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

--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c190200515223053d7e0e4f-- From nobody Tue Sep 27 23:16:24 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FC812B337; Tue, 27 Sep 2016 23:16:19 -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.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147504337900.11703.11201915015937263333.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 23:16:19 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 06:16:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-09.txt Pages : 23 Date : 2016-09-27 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiallity property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-09 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 30 13:04:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C52B12B025 for ; Fri, 30 Sep 2016 13:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji7vSPGmZBOJ for ; Fri, 30 Sep 2016 13:04:06 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FECE12B091 for ; Fri, 30 Sep 2016 13:04:06 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 15so10216188ita.1 for ; Fri, 30 Sep 2016 13:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=EspPfIVfXpvqXw99fU4j9F9o+NYueB9X6G8BIY1fQIE=; b=iNjJMDnwKu7SBcFhi6J1LnQjP0BtQC2tszt8Yt7djqIQM3Wqd9WRYQUsUEycV0AU6a a8DDWwBh7URiQiDc7XhTHm9eytgL9S6AFj+/XJOTmYRQwrjnZUGJxVyYIhHUziY44ObW d0zfm/v76+Wh1WJxwn7mgwjsm25sdwPAVHF/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EspPfIVfXpvqXw99fU4j9F9o+NYueB9X6G8BIY1fQIE=; b=ZLR3sEuyQbfssjZtsZE80Ug6uT2OqPsqhD8oGoYMQZolmODbu18jOGnyLePRKPdsdX syW3o0ztz51DASp22V7gFoa7fCZGZskBENTZ7vTjWHzNchjE+EaYp1tGaWqyhGd6tL3v sA2ejM3oIRisoZLx2Ki5iqwR/6bJo9wo6jnp1VT816xtPOj1vzYEqFad+L55LpknOlRy F5KM4eODh9B133N860O4oXVtq9eKjZpqWjT7425B3v6n30qME9N6fyr3UWxiC5eNsjbZ su5wARcn/pveGd20O2Bz+Jlpb2BUV/bhxJIb8LJG8CnWR3sY9DBqy/jg5BRpaOnu7Cge CwSg== X-Gm-Message-State: AA6/9RnkxQmPUj5uWHPR5wQno8j2xWQvK0wpo12COg5mjOZ6/CBPpXMoR0zTR23VkzmKSnTSxraDpfasPKUoqp/x X-Received: by 10.107.58.87 with SMTP id h84mr10673602ioa.122.1475265845068; Fri, 30 Sep 2016 13:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.141 with HTTP; Fri, 30 Sep 2016 13:03:34 -0700 (PDT) From: Brian Campbell Date: Fri, 30 Sep 2016 14:03:34 -0600 Message-ID: To: oauth , IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a114ac57aa522d7053dbf189b Archived-At: Subject: [OAUTH-WG] explicit/implicit signaling to reveal TB ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 20:04:08 -0000 --001a114ac57aa522d7053dbf189b Content-Type: text/plain; charset=UTF-8 Sending this to both the Tokbind and OAuth lists. There is text now in HTTPSTB that says that a TB ID must only be conveyed to a different server, if the associated server explicitly singles to do so. Specifically these two snippets, https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-5 has However, such applications MUST only convey Token Binding IDs to other servers if the server associated with a Token Binding ID explicitly signals to do so, e.g., by returning an Include-Referred- Token-Binding-ID HTTP response header field. and https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-7.3 has Also, applications must take care to only reveal Token Binding IDs to other endpoints if the server associated with a Token Binding ID explicitly signals to do so, see Section 5 "Implementation Considerations". This seems like it might be problematic for token binding of OAuth access tokens. Many/most OAuth flows don't begin at the resource sever (token consumer) but at the authorization server (token provider) so there's not an opportunity for such an explicit signal. And even when a request is made to the resource sever (token consumer) without a token or with a bad token, there isn't a redirect but rather a 40x is returned (see https://tools.ietf.org/html/rfc6750#section-3). The relationship between OAuth servers is much more of an implicit thing in how the OAuth client application (different than a browser client) interacts with those severs. And there's correlatable info already flowing between the two so revealing a referred TB doesn't make the privacy situation any different. But it can greatly improve the security of the access tokens. Can the text in HTTPSTB be reworked slightly to allow for an implicit okay or a prearrangement to reveal referred Token Binding IDs for applications which are not web browsers? Otherwise OAuth clients will have to ignore that MUST or a token (pun intended) but really meaningless signal will have to be invented for OAuth (like maybe a new auth-param with the WWW-Authenticate Response Header Field from RFC 6750. --001a114ac57aa522d7053dbf189b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sending this to both the Tokbind and OAuth lists.
=
There is text now in HTTPSTB that says that a TB ID must only be = conveyed to a different server, if the associated server explicitly singles= to do so. Specifically these two snippets,

https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-5 has

=C2=A0=C2=A0 H= owever, such applications MUST only convey Token Binding IDs to
=C2=A0= =C2=A0 other servers if the server associated with a Token Binding ID
= =C2=A0=C2=A0 explicitly signals to do so, e.g., by returning an Include-Ref= erred-
=C2=A0=C2=A0 Token-Binding-ID HTTP response header field.

=
and https://tools.ietf.org/html/draft-ietf-= tokbind-https-06#section-7.3 has

=C2=A0=C2=A0 Also, applic= ations must take care to only reveal Token Binding IDs to
=C2=A0=C2=A0 o= ther endpoints if the server associated with a Token Binding ID
=C2=A0= =C2=A0 explicitly signals to do so, see Section 5
=C2=A0=C2=A0 "Imp= lementation Considerations".


This seems like it might= be problematic for token binding of OAuth=20 access tokens. Many/most OAuth flows don't begin at the resource sever= =20 (token consumer) but at the authorization server (token provider) so=20 there's not an opportunity for such an explicit signal. And even when a= request is made to the resource sever=20 (token consumer) without a token or with a bad token, there isn't a red= irect but rather a 40x is returned (see https://tools.ietf.org/html/r= fc6750#section-3).

The relationship between OAuth servers is mu= ch more of an implicit thing in how the OAuth client application (different= than a browser client) interacts with those severs. And there's correl= atable info already flowing between the two so revealing a referred TB does= n't make the privacy situation any different. But it can greatly improv= e the security of the access tokens.

Can the text in HTTP= STB be reworked slightly to allow for an implicit okay or a prearrangement = to reveal referred Token Binding IDs for applications which are not web bro= wsers? Otherwise OAuth clients will have to ignore that MUST or a token (pu= n intended) but really meaningless signal will have to be invented for OAut= h (like maybe a new auth-param with the WWW-Authenticate Response Header Fi= eld from RFC 6750.



=C2=A0




--001a114ac57aa522d7053dbf189b--
In SPA/REST env sess= ion ID is not very useful, so it's *an* auth token or tokens (not necessary= OAuth one) that are stored in a cookie. It's used to get REST calls authen= ticated and yes, it usually runs in a multi-domain envs (think about micro = services architecture). It makes me think that the value of HTTPOnly will c= ontinue diminishing, while the value of good cross-domain policies will inc= rease. Just my opinion coming from my experience. I don't have big (or smal= l) data available to confirm that.  


From: Jim Manico <jim@manicode.com>
<= b id=3D"yui_3_16_0_ym19_1_1473365507813_3780">To: Oleg Gryb = <oleg@gryb.info>; Adam Lewis <adam.lewis@motorolasolutions.com>=
Cc: OAuth WG <oaut= h@ietf.org>
Sent: T= hursday, September 8, 2016 12:51 PM
Subject: Re: [OAUTH-WG] best practices for impli= cit grant / token storage

=
> Since SPA is a ne= w normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies.
In a browser environme= nt, this is only true when you need to make cross domain requests or are using cookie data for something other than session state.
If your current page origin and the page you are requesting are the same, then your cookies can be HTTPOnly without impacting functionality. If you need additional cookies for other things that need to be accessed via JS, use a separate cookie.
So sure, there are a f= ew workflows in OAuth where you need to access "cookie data" from JS and HTTPOnly is not viable. But there are a few where it is viable. I don't think it's as simple as "we need to talk to cookie data via JS all the time.".
Aloha, Jim
=
On 9/8/16 8:15 AM, Oleg Gryb wr= ote:
Jim,<= /div>

It's outdated a bit. Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies. 5-10 years ago I would always enforce HTTPOnly and now - I can't.

Thanks,
Oleg.
From: Jim Manico <jim@manicode.com>
To: Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, September 8, 2016 10:45 AM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

In the web world, cookies for session identifiers are much safer - since we can use HTTPOnly cookies to protect them from theft via XSS. The same mechanism is not possible for localStorage. Overall, security folk say =E2=80=A2keep sensitive = data out of localStorage=E2=80=A2 since one XSS and it's stolen. There is also a huge body of work underway to make secure cookies even more so.

I'm not sure how this translates to native apps.

--
Jim Manico
@Manicode

On Sep 8, 2016, at 3:02 AM, Adam Lewis <ad= am.lewis@motorolasolutions.com> wrote:

Hi,

The WG is currently putting together best practices for native apps.  I would like to better understand the best practices around ua-based-apps, especially as it relates to token storage.  I've= read various blog posts about the preference between storing tokens in cookies vs.  Web Storage (localStorage/sessionStorage).  The current set of specs are rather silent on the matter, as it is more of an implementation issue (but that is where most mistakes are made).

What is the WG's guidance on this?
________________________________________= _______
OAuth mailing list
OAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth

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



--=20
Jim Manico
Manicode Security
https://www.manic=
ode.com

____________= ___________________________________
OAuth mailing listOAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth

"keep away from implicit grants and do not store bearer tokens in the browser" - that would be practi= cally impossible for the envs that I was writing about and "best practices"=   that could not be enforced aren't worth much. I can formulate it in = stronger terms: if OAuth wouldn't allow a JS client running in a browser it= s usability will be very low.

What could and should be improved in implicit grants i= s removing secrets from URL (fragment). That could be done as I've shown in= the previous discussions.


From: Jim Manico <jim@manicode.com>
To: John Bradley <ve7jtb@ve7jtb.com&= gt;
Cc: Oleg Gryb <= oleg@gryb.info>; Adam Lewis <adam.lewis@motorolasolutions.com>; OA= uth WG <oauth@ietf.org>
Sen= t: Thursday, September 8, 2016 3:51 PM
Subject: Re: [OAUTH-WG] best practices for impl= icit grant / token storage

+1000 on a OAuth Secur= ity Best Practices document. I'd be happy to review or help some.
I think right now the = answer is: keep away from implicit grants and do not store bearer tokens in the browser. Instead, use the authorization code grant which only exposes bearer tokens intra-server.
For web apps, I feel the only good place to = store authentication, session or token information is in a HTTPOnly flagged cookie to keep JS away from sensitive information.

Aloha, Jim


On 9/8/16 12:38 PM, John Br= adley wrote:
It is an interesting discussion, indicating that perhaps a best practices document is in order.

I have had several people ask me about S= PA using OAuth recently.

Until we get the W3C to finish fetch and= extend it for token binding, we are going to have ongoing issues with bearer tokens in the browser and where to store them.

I don=E2=80=99t know that there is a per= fect solution for bearer tokens, but documenting the tradeoffs may be useful.

John B.

On Sep 8, 2016, at 6:07 PM, Jim Ma= nico <jim@manicode.com> wrote:

+1 I think that's a very fair = perspective.
Putting sensitive data in Loca= lStorage is still a very bad idea. :) One XSS and gone. Maybe XSS is not a big deal in a native app, but it's death to Web apps.
Aloha, Jim

On 9/8/16 10:20= AM, Oleg Gryb wrote:
In SPA/REST env session ID is not very useful, so it's *an* auth token or tokens (not necessary OAuth one) that are stored in a cookie. It's used to get REST calls authenticated and yes, it usually runs in a multi-domain envs (think about micro services architecture). It makes me think that the value of HTTPOnly will continue diminishing, while the value of good cross-domain policies will increase. Just my opinion coming from my experience. I don't have big (or small) data available to confirm that.  


From= : Jim Manico <jim@manicod= e.com>
To: Oleg Gryb <oleg@gryb.info&g= t;; Adam Lewis <adam.lewis@motorolasolutions.com>
Cc: OAuth WG <oauth@ietf.org><= br class=3D"yiv1973459442" clear=3D"none"> Sent: Thursday, September 8, 2016 12:51 PM
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

> Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies.
In a browser environment, this is only true when you need to make cross domain requests or are using cookie data for something other than session state.
If your curr= ent page origin and the page you are requesting are the same, then your cookies can be HTTPOnly without impacting functionality. If you need additional cookies for other things that need to be accessed via JS, use a separate cookie.
So sure, there are a few workflows in OAuth where you need to access "cookie data" from JS and HTTPOnly is not viable. But there are a few where it is viable. I don't think it's as simple as "we need to talk to cookie data via JS all the time.".
Aloha, Jim
On 9/8/16 8:15 AM, Oleg Gryb wrote:
Jim,

It's outdate= d a bit. Since SPA is a new normal now, it becomes extremely difficult to enforce HTTPOnly flag, because JS needs access to secrets including those stored in cookies. 5-10 years ago I would always enforce HTTPOnly and now - I can't.

Thanks,
Oleg.
From: Jim Manico <= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv1973459442moz-txt-link-rfc239= 6E" ymailto=3D"mailto:jim@manicode.com" target=3D"_blank" href=3D"mailto:ji= m@manicode.com"><jim@manicode.com>
To: Adam Lewis <adam.lewis@motorolasolutions.com&g= t;
Cc: OAuth WG <= ;oauth@ietf.org>
Sent: Thursday, September 8, 2016 10:45 AM
Subject:= Re: [OAUTH-WG] best practices for implicit grant / token storage
<= br class=3D"yiv1973459442" clear=3D"none">
In the web world, cookies for session identifiers are much safer - since we can use HTTPOnly cookies to protect them from theft via XSS. The same mechanism is not possible for localStorage. Overall, security folk say =E2=80=A2keep sensitive data out of localStorage=E2=80= =A2 since one XSS and it's stolen. There is also a huge body of work underway to make secure cookies even more so.

I'm not sure how this translates to native apps.

--
Jim Manico
@Manicode

On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Hi,

The WG is currently putting together best practices for native apps. = ; I would like to better understand the best practices around ua-based-apps, especially as it relates to token storage.  I've read various blog posts about the preference between storing tokens in cookies vs.  We= b Storage (localStorage/ses= sionStorage).  The current set of specs are rather silent on the matter, as it is more of an implementation issue (but that is where most mistakes are made).=

What is the WG's guidance on this?
___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https:/= /www.ietf.org/mailman/listinfo/oauth

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



--=20
Jim Manico
Manicode Security
https://www.manic=
ode.com

_______________________________________________<= br class=3D"yiv1973459442" clear=3D"none"> OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--=20
Jim Manico
Manicode Security
https://www.manic=
ode.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=20 =20 =20
=20 =20 
--=20
Jim Manico
Manicode Security
https://www.manic=
ode.com