From nobody Sun Sep 3 15:27:13 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE3E126B71 for ; Sun, 3 Sep 2017 15:27:12 -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=rtfm-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 Np8xeyNauvE4 for ; Sun, 3 Sep 2017 15:27:10 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 2B965124205 for ; Sun, 3 Sep 2017 15:27:10 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id t188so18575271ywb.1 for ; Sun, 03 Sep 2017 15:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=VPVLBcSgUS9XBdiF8FqBfEDqhulw0xsit1qpCa6LO1U=; b=q776IfN+ZpioTTzkllFbVt2kGiJOSq3JVWD7In/cYKcN9kaGHh75j0kTCm7j83hC42 Ev8Ev2vzJ/84PPv1TFmbEoCrMEBXy1QOQqmamtntaz6dncNUFM25s9icFuGXI8//Y+EZ AXzyrQM+Y0yeMcnyMlGLCBiDi3A//R27+jZP1v5RHy0PCCfcYZgC7h12YjsSbUn/RX7h q3ah/6JqEhcLUadDhvoKwS2ue3q8rrsdeOA5cV9fg2wGTTyWxEcgQo4zeC8eCiSavdx7 1NZNuczFKDPtXi7S3Sq132engejmGJtYw5fvTXtm+JmtDq/B8xUPrPtkNmbiLDoVDUJq +jjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VPVLBcSgUS9XBdiF8FqBfEDqhulw0xsit1qpCa6LO1U=; b=SbuBIEbmdMlxkHUpJZfHx7UiGBYTqnOaD3lpeUuWzh1xOJnDQoTbcq7wm6hR9lcC9r 2YiZb90ezLO63Pp1M6GhIxpcEFfiZ11O7bKF9I4i4zC+qU9sruJBUt0OGMJ5vSEXCO/M H13dL9YT+oqdUjTYob3Or97X9hxx43pgbxaqAtOFN02FT3bKYdNRyyesGev3BioyHJTK On1G9DHs4aDgZJCm8+n1JSm6f5N+jSmkcetmFoAVeYSfc6g2VLRprjDNEOUnBfpQJDgJ VI6M2HK5CMjbo3CBYeH0xXTFiO2esGZaSAnpNlpM/3S6HWDYkgZ42jCpY9tjZkOfX7mH 0gmg== X-Gm-Message-State: AHPjjUjd6m09iXHXt6QeqsyDDTUC7nrkAKpk1lwF8qQiaGXCpe62tZZs VcmL2WQmffMLM5WjUkFDPwNlzZ0XQa+6LKi/tA== X-Google-Smtp-Source: ADKCNb7TA+bf4p6BR4U44EkXCYMI7Lbc/HeUCMptZ4iKAAZW+0l3xTeC13Bj4RCXLLpmMJmV6cB3wD5XBB8sL/oBr3Y= X-Received: by 10.129.137.199 with SMTP id z190mr8164338ywf.72.1504477629111; Sun, 03 Sep 2017 15:27:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sun, 3 Sep 2017 15:26:28 -0700 (PDT) From: Eric Rescorla Date: Sun, 3 Sep 2017 15:26:28 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="94eb2c064548a7fbc20558507ec7" Archived-At: Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 22:27:12 -0000 --94eb2c064548a7fbc20558507ec7 Content-Type: text/plain; charset="UTF-8" Hi folks, Note: the original of this review is on Phabricator at: https://mozphab-ietf.devsvcdev.mozaws.net/D7 If you want to see comments in context, you can go there. Also, you can create an account and respond inline if you like. If you elect to, let me know if you run into problems. -Ekr I have marked a number of places where it seems like you either need defaults or need to indicate what the semantics are if missing This metadata can either be communicated in a self-asserted fashion or as a set of signed metadata values represented as claims in a JSON I assume "self-asserted" in this case means "asserted by the server origin via HTTPS" Line 222 authentication methods. Servers SHOULD support "RS256". The value "none" MUST NOT be used. What's the default if omitted? Line 235 represented as a JSON array of BCP47 [RFC5646] language tag values. What's the default if omitted? Line 267 "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters]. What's the default if omitted? Line 275 "client_secret_jwt" authentication methods. The value "none" MUST NOT be used. What's the default if omitted? Line 288 Access Token Types" registry [IANA.OAuth.Parameters]. (These values are and will remain distinct, due to Section 7.2.) What's the default if omitted? Line 296 "client_secret_jwt" authentication methods. The value "none" MUST NOT be used. What's the default if omitted? Line 304 challenge method values are those registered in the IANA "PKCE Code Challenge Methods" registry [IANA.OAuth.Parameters]. What's the default if omitted? Line 343 MUST be registered in the IANA "Well-Known URIs" registry [IANA.well-known]. IMPORTANT: Shouldn't this be required to be HTTPS Line 500 client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. Implementation security considerations can be found in Recommendations for Secure Use of TLS and DTLS [BCP195]. Hmm.... I'm unsure about whether this should be a citation to 2818. Is the general feeling that 6125 superceded 2818? Line 564 The following registration procedure is used for the registry established by this specification. This section seems like it needs RFC2119 language Line 568 Values are registered on a Specification Required [RFC5226] basis after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. What happens if you don't do anything within two weeks. Line 756 o Change Controller: IESG o Specification Document(s): Section 2 of [[ this specification ]] Extra whitespace. --94eb2c064548a7fbc20558507ec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

Note: the original= of this review is on Phabricator at:


If you want to see comme= nts in context, you can go there. Also,
you can create an account= and respond inline if you like.
If you elect to, let me know if = you run into problems.

-Ekr


I have marked a number of places where it seems like you = either need
defaults or need to indicate what the semantics are i= f missing


=C2=A0 =C2=A0This metadat= a can either be communicated in a self-asserted fashion
=C2=A0 = =C2=A0or as a set of signed metadata values represented as claims in a JSON=
I assume "self-asserted" in this case means "asse= rted by the server origin via HTTPS"


Line 222
=C2=A0 =C2=A0 =C2=A0 authentication methods.=C2= =A0 Servers SHOULD support "RS256".=C2=A0 The
=C2=A0 = =C2=A0 =C2=A0 value "none" MUST NOT be used.
What's= the default if omitted?


Line 235
=C2=A0 =C2=A0 =C2=A0 represented as a JSON array of BCP47 [RFC5646= ] language tag
=C2=A0 =C2=A0 =C2=A0 values.
What's = the default if omitted?


Line 267
=C2=A0 =C2=A0 =C2=A0 "OAuth Token Endpoint Authentication Meth= ods" registry
=C2=A0 =C2=A0 =C2=A0 [IANA.OAuth.Parameters].<= /div>
What's the default if omitted?


<= /div>
Line 275
=C2=A0 =C2=A0 =C2=A0 "client_secret_jwt&q= uot; authentication methods.=C2=A0 The value "none" MUST
=C2=A0 =C2=A0 =C2=A0 NOT be used.
What's the default if omi= tted?


Line 288
=C2=A0 =C2= =A0 =C2=A0 Access Token Types" registry [IANA.OAuth.Parameters]. =C2= =A0(These
=C2=A0 =C2=A0 =C2=A0 values are and will remain distinc= t, due to Section 7.2.)
What's the default if omitted?
<= div>

Line 296
=C2=A0 =C2=A0 =C2=A0 &= quot;client_secret_jwt" authentication methods.=C2=A0 The value "= none" MUST
=C2=A0 =C2=A0 =C2=A0 NOT be used.
What&= #39;s the default if omitted?


Line = 304
=C2=A0 =C2=A0 =C2=A0 challenge method values are those regist= ered in the IANA "PKCE
=C2=A0 =C2=A0 =C2=A0 Code Challenge M= ethods" registry [IANA.OAuth.Parameters].
What's the def= ault if omitted?

Line 343
=C2=A0 =C2=A0M= UST be registered in the IANA "Well-Known URIs" registry
=C2=A0 =C2=A0[IANA.well-known].
IMPORTANT: Shouldn't this b= e required to be HTTPS

Line 500
=C2=A0 = =C2=A0client MUST perform a TLS/SSL server certificate check, per RFC 6125<= /div>
=C2=A0 =C2=A0[RFC6125].=C2=A0 Implementation security considerati= ons can be found in
=C2=A0 =C2=A0Recommendations for Secure Use o= f TLS and DTLS [BCP195].
Hmm.... I'm unsure about whether thi= s should be a citation to 2818. Is the general feeling that 6125 superceded= 2818?


Line 564
=C2=A0 = =C2=A0The following registration procedure is used for the registry
=C2=A0 =C2=A0established by this specification.
This section s= eems like it needs RFC2119 language


Line 568
=C2=A0 =C2=A0Values are registered on a Specification R= equired [RFC5226] basis
=C2=A0 =C2=A0after a two-week review peri= od on the oauth-ext-review@iet= f.org
=C2=A0 =C2=A0mailing list, on the advice of one or more= Designated Experts.
What happens if you don't do anything wi= thin two weeks.


Line 756
= =C2=A0 =C2=A0o =C2=A0Change Controller: IESG
=C2=A0 =C2=A0o =C2= =A0Specification Document(s): Section 2 of [[ this specification ]]
Extra whitespace.

--94eb2c064548a7fbc20558507ec7-- From nobody Tue Sep 5 08:14:04 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB717132D52 for ; Tue, 5 Sep 2017 08:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gNAuODELf90 for ; Tue, 5 Sep 2017 08:14:01 -0700 (PDT) Received: from SMTPGATE01.enterexchange.com (smtpgate01.enterexchange.com [109.205.192.241]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E7F124207 for ; Tue, 5 Sep 2017 08:14:00 -0700 (PDT) From: Jaap Francke To: "oauth@ietf.org" Thread-Topic: Using OAuth for password reset Thread-Index: AQHTJlmXd9rKfP1n0UmGaoCZoW8DPw== Date: Tue, 5 Sep 2017 15:13:56 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.17.5.138] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Using OAuth for password reset X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:14:03 -0000 SGkgYWxsLA0KDQpJIHdhcyB3b25kZXJpbmcgaWYgYW55b25lIGNvbnNpZGVyZWQgdXNpbmcgT0F1 dGggZm9yIHBhc3N3b3JkIHJlc2V0cy4gT3IgbWF5YmUgdGhpcyBpcyBjb21tb24gcHJhY3RpY2Us IEkgZG9u4oCZdCBrbm93Lg0KDQpNeSBsaW5lIG9mIHRoaW5raW5nIGlzIHRoYXQgYSBwYXNzd29y ZCBpcyAianVzdC1hbm90aGVyLXJlc291cmNlIiB0aGF0IGlzIHN0b3JlZCBhdCBhIHJlc291cmNl IHNlcnZlci4NClNvIHRoZSByZXNvdXJjZSBzZXJ2ZXIgcmVxdWlyZXMgYW4gYWNjZXNzIHRva2Vu IGZvciBhbnlvbmUvYW55IGNsaWVudCB0aGF0IHdhbnRzIHRvIHVwZGF0ZS9jaGFuZ2UgdGhlIHBh c3N3b3JkLg0KVGhlIGF1dGhvcmlzYXRpb24gc2VydmVyIHRoYXQgaXNzdWVzIGFjY2Vzcy10b2tl bnMgc29tZWhvdyBuZWVkcyB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCB0aGF0IHdhbnRzIGFu IGFjY2VzcyB0b2tlbiBmb3IgY2hhbmdpbmcgYSBjZXJ0YWluIHBhc3N3b3JkLg0KDQpBdXRoZW50 aWNhdGlvbiBpcyBoYWxmIGluLXNjb3BlIGFuZCBoYWxmIG91dC1vZi1zY29wZSBvZiBPQXV0aCBz cGVjaWZpY2F0aW9ucy4NCkluIHRoZSBBdXRob3Jpc2F0aW9uIENvZGUgZ3JhbnQgKEFDKSwgaXQg aXMgbGVmdCBvdXQtb2Ytc2NvcGUgaG93IHRoZSBBUyBhdXRoZW50aWNhdGVzIHRoZSBSTywgYnV0 IGl0IGRvZXMgc3RhdGUgaXQgc2hvdWxkIGhhcHBlbiB0aHJvdWdoIHRoZSB1c2VyLWFnZW50IGR1 cmluZyB0aGUgZXhlY3V0aW9uIG9mIHRoZSBncmFudC4NCkluIHRoZSBSZXNvdXJjZU93bmVyIHBh c3N3b3JkIGNyZWRlbnRpYWwgKFJPUEMpIGdyYW50LCB0aGUgdXNlcm5hbWUvcGFzc3dvcmQgaXMg c2VudCB0byB0aGUgQVMgYXMgcGFydCBvZiB0aGUgYXV0aG9yaXNhdGlvbiByZXF1ZXN0IC8gcmVk aXJlY3QuDQoNCkZvciBhIHBhc3N3b3JkIHJlc2V0IHNjZW5hcmlvLCBJIHdvdWxkIHNheSB3ZSBu ZWVkIGEgbmV3IGdyYW50IHdoaWNoIHdvdWxkIGJlIGluYmV0d2VlbiBBQy1ncmFudCBhbmQgUk9Q Qy1ncmFudDoNCi0gaXQgc3RhcnRzIHdpdGggYSByZWRpcmVjdCB0byB0aGUgQVMgaW5jbHVkaW5n IGEg4oCccGFzc3dvcmQgcmVzZXQgdG9rZW7igJ0gLSBzb21ld2hhdCBzaW1pbGFyIHRvIHRoZSBS T1BDLWdyYW50OiB0aGUgcGFzc3dvcmQgcmVzZXQtdG9rZW4gY2FuIGJlIHZpZXdlZCBhcyBjb21i aW5hdGlvbiBvZiB1c2VybmFtZSBhbmQgYSAob25lLXRpbWUpIHBhc3N3b3JkLiBUaGlzIGlzIGJh c2ljYWxseSBjbGlja2luZyBvbiBhIHBhc3N3b3JkIHJlc2V0IGxpbmsNCi0gc3Vic2VxdWVudGx5 IHRoZSBBUyBjb3VsZCBwZXJmb3JtIGFkZGl0aW9uYWwgYXV0aGVudGljYXRpb24gc3RlcHMgKGUu Zy4gMkZBLVNNUykgLSBzaW1pbGFyIHRvIHdoYXQgaXMgcG9zc2libGUgd2l0aCB0aGUgQUMtZ3Jh bnQNCi0gd2hlbiBBUyB0aGlua3MgdGhlIHVzZXIgaXMgc3VmZmljaWVudGx5IGF1dGhlbnRpY2F0 ZWQsIHRoZSBBUyBjb3VsZCBpc3N1ZSB0aGUgYXV0aG9yaXNhdGlvbiBjb2RlIGFuZCB0aGluZ3Mg d291bGQgcHJvY2VlZCBhcyB3aXRoIHRoZSBBQy1ncmFudA0KDQpPYnZpb3VzbHkgdGhpcyBpcyBw cmVjZWVkZWQgYnkgYSByZXF1ZXN0IGZvciBhIHBhc3N3b3JkLXJlc2V0IGxpbmssIHdoaWNoIGdl dHMgc2VudCB0byB0aGUgbGVnaXRpbWF0ZSByZXNvdXJjZSBvd25lciBPdXQtT2YtQm91bmQgdmlh IGVtYWlsLCBTTVMsIG9yIHdoYXRzb2V2ZXIuDQoNCkFtIEkgbWFraW5nIHRoaW5ncyB0b28gY29t cGxpY2F0ZWQgaGVyZT8gT3Igd291bGQgdGhpcyBiZSB0aGUgcHJvcGVyIHdheSB0byBkbyBpdD8g SeKAmW0gdHJ5aW5nIHRvIGhvb2stdXAgdG8gdGhlIG1vc3Qgc2VjdXJlIE9BdXRoIG1lY2hhbmlz bXMuDQpBbnkgdGhvdWdodHM/DQoNCkphYXAgRnJhbmNrZQ== From nobody Tue Sep 5 16:11:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D4A132E3A for ; Tue, 5 Sep 2017 16:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMactQYl3Chf for ; Tue, 5 Sep 2017 16:11:56 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0129.outbound.protection.outlook.com [104.47.40.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD5A132199 for ; Tue, 5 Sep 2017 16:11: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=MLlA/ekDDKoEZn1hd43kwu0hdH8mFERvnFxZRkMLPHE=; b=hRKvY3Q+bsyzakEjWFNo/D4TmqLvRv9dQou2lO7e8Moxpil1qdHqgZH5PcF3TttItW7H4OEVmGUwThNTPNeFqWc5bVxHW6RPnieHH8KCPsJQbut2VFbQnnO+hJcAjSexwUvNqWmxoCGbGfQp3d1KvYC4rSv7ZO3k1KXODvUnQY4= Received: from BN6PR21MB0500.namprd21.prod.outlook.com (10.172.112.10) by BN6PR21MB0499.namprd21.prod.outlook.com (10.172.112.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.35.0; Tue, 5 Sep 2017 23:11:54 +0000 Received: from BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) by BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) with mapi id 15.20.0035.002; Tue, 5 Sep 2017 23:11:54 +0000 From: Mike Jones To: Eric Rescorla , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 Thread-Index: AQHTJQPOGSEV1sPnL0a/osPnuKlQ5aKm2zkw Date: Tue, 5 Sep 2017 23:11:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-09-05T16:11:52.0851161-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0499; 6:+5uE7koHvzjUldXLlZP2x+3by6JSfr0281MzKAIn3AeIilZtV7xIMI8CYuaNd5NTn+MlAHrovoE42oQexl19JGF4P5j+vaWwtpln7EGFG64c9mjJXinO4aBSjjcVPeTCgC4MZkc9NtkiBFoaQtftxAqhRMrwsJjD5Y+FVNmsjJegVpItW+mdSKMR7RfXaESp2WrraDH4Dr1yJ7oJgepXbMPxWocDBnmofdB3whzTDvgEzCP31Is1kNFpNJ7V+la10SyeJY2mKXfrO4wN1DqFZvHZu478LYGDmMV3Dh9IuNm++lvcDBLFFc6zhGo+2YbitryMNjE/A+vOOy0g531gEg==; 5:6MOH2jLDQCKVmPvvI3/eRTtHZLEZBScXtmw9hYZb6jrYfAOzagxQZIZ1Te7Va2CAYNmCIdUbm0nuxxZsXxVlae1yyI82uS74eiaEPd6QItrtQPJ2jjBGBRd43B1/dDUhFZhvc/Tj2XY3Zmvwt2yoEg==; 24:CUCDN0rn+MLXYU8t3bUr7Znkjk0G1rko1jOxiXI2qlTnvI+zXUM5X9J85Ugw6YxnwF2ajOmhUu5cIT3VhTFESQu7gAvGlnIcao3LebaqW8E=; 7:Aw/AjGrjykDj8Y90vMm0NL9DgVPTigk6b8J3rTCfw5XUco1crIc9sWZUKmnT4hYT564gWtnE1zidCHW4bNAH23T5Roj5YbYvT7Q1QOr47GuVqZPomZzxHwCl9MUX82APVnyvcf/INCC00g96CNCS8iRwSRyGzhwRDrMycoh0HCrygVELv5Km4gDruZWqytF8b6ULgW6Obwqu6wVxjWxgOaqOZawmGbPtcHKMbAZiv+4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 507099f1-83e1-4227-7f68-08d4f4b37fce x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR21MB0499; x-ms-traffictypediagnostic: BN6PR21MB0499: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR21MB0499; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR21MB0499; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(199003)(377454003)(189002)(86612001)(2906002)(3660700001)(478600001)(74316002)(6436002)(189998001)(86362001)(25786009)(3280700002)(2950100002)(7696004)(72206003)(9686003)(6306002)(6246003)(55016002)(8990500004)(5005710100001)(99286003)(97736004)(10290500003)(5660300001)(6116002)(102836003)(53936002)(10090500001)(2501003)(101416001)(230783001)(2900100001)(54356999)(68736007)(966005)(7736002)(76176999)(50986999)(305945005)(81156014)(77096006)(53546010)(229853002)(8936002)(6506006)(33656002)(14454004)(81166006)(105586002)(8676002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0499; H:BN6PR21MB0500.namprd21.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: 05 Sep 2017 23:11:54.5974 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0499 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 23:11:58 -0000 VGhhbmtzIGZvciB5b3VyIHVzZWZ1bCByZXZpZXcsIEVyaWMuICBQcm9wb3NlZCByZXNvbHV0aW9u cyB0byBhbGwgY29tbWVudHMgYXJlIGlubGluZSBwcmVmaXhlZCBieSAiTWlrZT4iLg0KDQpGcm9t OiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmlj IFJlc2NvcmxhDQpTZW50OiBTdW5kYXksIFNlcHRlbWJlciAzLCAyMDE3IDM6MjYgUE0NClRvOiBv YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYt b2F1dGgtZGlzY292ZXJ5LTA2DQoNCkhpIGZvbGtzLA0KDQpOb3RlOiB0aGUgb3JpZ2luYWwgb2Yg dGhpcyByZXZpZXcgaXMgb24gUGhhYnJpY2F0b3IgYXQ6DQoNCsKgIGh0dHBzOi8vbW96cGhhYi1p ZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q3DQoNCklmIHlvdSB3YW50IHRvIHNlZSBjb21tZW50 cyBpbiBjb250ZXh0LCB5b3UgY2FuIGdvIHRoZXJlLiBBbHNvLA0KeW91IGNhbiBjcmVhdGUgYW4g YWNjb3VudCBhbmQgcmVzcG9uZCBpbmxpbmUgaWYgeW91IGxpa2UuDQpJZiB5b3UgZWxlY3QgdG8s IGxldCBtZSBrbm93IGlmIHlvdSBydW4gaW50byBwcm9ibGVtcy4NCg0KLUVrcg0KDQoNCkkgaGF2 ZSBtYXJrZWQgYSBudW1iZXIgb2YgcGxhY2VzIHdoZXJlIGl0IHNlZW1zIGxpa2UgeW91IGVpdGhl ciBuZWVkDQpkZWZhdWx0cyBvciBuZWVkIHRvIGluZGljYXRlIHdoYXQgdGhlIHNlbWFudGljcyBh cmUgaWYgbWlzc2luZw0KDQoNCsKgIMKgVGhpcyBtZXRhZGF0YSBjYW4gZWl0aGVyIGJlIGNvbW11 bmljYXRlZCBpbiBhIHNlbGYtYXNzZXJ0ZWQgZmFzaGlvbg0KwqAgwqBvciBhcyBhIHNldCBvZiBz aWduZWQgbWV0YWRhdGEgdmFsdWVzIHJlcHJlc2VudGVkIGFzIGNsYWltcyBpbiBhIEpTT04NCkkg YXNzdW1lICJzZWxmLWFzc2VydGVkIiBpbiB0aGlzIGNhc2UgbWVhbnMgImFzc2VydGVkIGJ5IHRo ZSBzZXJ2ZXIgb3JpZ2luIHZpYSBIVFRQUyINCg0KTWlrZT4gVGhhbmtzIC0gSSB3aWxsIHVzZSB0 aGlzIGxhbmd1YWdlLg0KDQpMaW5lIDIyMg0KwqAgwqAgwqAgYXV0aGVudGljYXRpb24gbWV0aG9k cy7CoCBTZXJ2ZXJzIFNIT1VMRCBzdXBwb3J0ICJSUzI1NiIuwqAgVGhlDQrCoCDCoCDCoCB2YWx1 ZSAibm9uZSIgTVVTVCBOT1QgYmUgdXNlZC4NCldoYXQncyB0aGUgZGVmYXVsdCBpZiBvbWl0dGVk Pw0KDQpNaWtlPiBJIHdpbGwgYWRkICJJZiBvbWl0dGVkLCB0aGVzZSBhdXRoZW50aWNhdGlvbiBt ZXRob2RzIGNhbm5vdCBiZSB1c2VkLiINCg0KTGluZSAyMzUNCsKgIMKgIMKgIHJlcHJlc2VudGVk IGFzIGEgSlNPTiBhcnJheSBvZiBCQ1A0NyBbUkZDNTY0Nl0gbGFuZ3VhZ2UgdGFnDQrCoCDCoCDC oCB2YWx1ZXMuDQpXaGF0J3MgdGhlIGRlZmF1bHQgaWYgb21pdHRlZD8NCg0KTWlrZT4gVGhlcmUg aXMgbm8gZGVmYXVsdC4gIEkgd2lsbCBhZGQgIklmIG9taXR0ZWQsIHRoZSBzZXQgb2Ygc3VwcG9y dGVkIGxhbmd1YWdlcyBhbmQgc2NyaXB0cyBpcyB1bnNwZWNpZmllZC4iDQoNCkxpbmUgMjY3DQrC oCDCoCDCoCAiT0F1dGggVG9rZW4gRW5kcG9pbnQgQXV0aGVudGljYXRpb24gTWV0aG9kcyIgcmVn aXN0cnkNCsKgIMKgIMKgIFtJQU5BLk9BdXRoLlBhcmFtZXRlcnNdLg0KV2hhdCdzIHRoZSBkZWZh dWx0IGlmIG9taXR0ZWQ/DQoNCk1pa2U+IEkgd2lsbCBhZGQgY2xpZW50X3NlY3JldF9iYXNpYyBh cyB0aGUgZGVmYXVsdCAtIGp1c3QgbGlrZSBpdCBhbHJlYWR5IHdhcyBmb3IgdG9rZW5fZW5kcG9p bnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZC4NCg0KTGluZSAyNzUNCsKgIMKgIMKgICJjbGllbnRf c2VjcmV0X2p3dCIgYXV0aGVudGljYXRpb24gbWV0aG9kcy7CoCBUaGUgdmFsdWUgIm5vbmUiIE1V U1QNCsKgIMKgIMKgIE5PVCBiZSB1c2VkLg0KV2hhdCdzIHRoZSBkZWZhdWx0IGlmIG9taXR0ZWQ/ DQoNCk1pa2U+IEkgd2lsbCBhZGQgIklmIG9taXR0ZWQsIHRoZXNlIGF1dGhlbnRpY2F0aW9uIG1l dGhvZHMgY2Fubm90IGJlIHVzZWQuIg0KDQpMaW5lIDI4OA0KwqAgwqAgwqAgQWNjZXNzIFRva2Vu IFR5cGVzIiByZWdpc3RyeSBbSUFOQS5PQXV0aC5QYXJhbWV0ZXJzXS4gwqAoVGhlc2UNCsKgIMKg IMKgIHZhbHVlcyBhcmUgYW5kIHdpbGwgcmVtYWluIGRpc3RpbmN0LCBkdWUgdG8gU2VjdGlvbiA3 LjIuKQ0KV2hhdCdzIHRoZSBkZWZhdWx0IGlmIG9taXR0ZWQ/DQoNCk1pa2U+IFRoZXJlIGlzIG5v IG9idmlvdXMgZGVmYXVsdC4gIFRoZXJlZm9yZSwgSSB3aWxsIGFkZCAiSWYgb21pdHRlZCwgdGhl IHNldCBvZiBzdXBwb3J0ZWQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBNVVNUIGJlIGRldGVybWlu ZWQgYnkgb3RoZXIgbWVhbnMuIg0KDQpMaW5lIDI5Ng0KwqAgwqAgwqAgImNsaWVudF9zZWNyZXRf and0IiBhdXRoZW50aWNhdGlvbiBtZXRob2RzLsKgIFRoZSB2YWx1ZSAibm9uZSIgTVVTVA0KwqAg wqAgwqAgTk9UIGJlIHVzZWQuDQpXaGF0J3MgdGhlIGRlZmF1bHQgaWYgb21pdHRlZD8NCg0KTWlr ZT4gSSB3aWxsIGFkZCAiSWYgb21pdHRlZCwgdGhlc2UgYXV0aGVudGljYXRpb24gbWV0aG9kcyBj YW5ub3QgYmUgdXNlZC4iDQoNCkxpbmUgMzA0DQrCoCDCoCDCoCBjaGFsbGVuZ2UgbWV0aG9kIHZh bHVlcyBhcmUgdGhvc2UgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSAiUEtDRQ0KwqAgwqAgwqAgQ29k ZSBDaGFsbGVuZ2UgTWV0aG9kcyIgcmVnaXN0cnkgW0lBTkEuT0F1dGguUGFyYW1ldGVyc10uDQpX aGF0J3MgdGhlIGRlZmF1bHQgaWYgb21pdHRlZD8NCg0KTWlrZT4gSSB3aWxsIGFkZCAiSWYgb21p dHRlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgUEtDRS4iDQoN CkxpbmUgMzQzDQrCoCDCoE1VU1QgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSAiV2VsbC1Lbm93 biBVUklzIiByZWdpc3RyeQ0KwqAgwqBbSUFOQS53ZWxsLWtub3duXS4NCklNUE9SVEFOVDogU2hv dWxkbid0IHRoaXMgYmUgcmVxdWlyZWQgdG8gYmUgSFRUUFMNCg0KTWlrZT4gSSB3aWxsIGFkZCAi VGhpcyBwYXRoIE1VU1QgdXNlIHRoZSAiaHR0cHMiIHNjaGVtZS4iDQoNCkxpbmUgNTAwDQrCoCDC oGNsaWVudCBNVVNUIHBlcmZvcm0gYSBUTFMvU1NMIHNlcnZlciBjZXJ0aWZpY2F0ZSBjaGVjaywg cGVyIFJGQyA2MTI1DQrCoCDCoFtSRkM2MTI1XS7CoCBJbXBsZW1lbnRhdGlvbiBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBjYW4gYmUgZm91bmQgaW4NCsKgIMKgUmVjb21tZW5kYXRpb25zIGZvciBT ZWN1cmUgVXNlIG9mIFRMUyBhbmQgRFRMUyBbQkNQMTk1XS4NCkhtbS4uLi4gSSdtIHVuc3VyZSBh Ym91dCB3aGV0aGVyIHRoaXMgc2hvdWxkIGJlIGEgY2l0YXRpb24gdG8gMjgxOC4gSXMgdGhlIGdl bmVyYWwgZmVlbGluZyB0aGF0IDYxMjUgc3VwZXJjZWRlZCAyODE4Pw0KDQpNaWtlPiBPQXV0aCAy LjAgW1JGQyA2NzQ5XSBhbHNvIHJlcXVpcmVzIGFuIFJGQyA2MTI1IGNlcnRpZmljYXRlIHZhbGlk YXRpb24sIHNvIHRoaXMgaXMgaW4gbGluZSB3aXRoIG90aGVyIHVzZXMgb2YgdGhlIE9BdXRoIHBy b3RvY29sIGZhbWlseS4NCg0KTGluZSA1NjQNCsKgIMKgVGhlIGZvbGxvd2luZyByZWdpc3RyYXRp b24gcHJvY2VkdXJlIGlzIHVzZWQgZm9yIHRoZSByZWdpc3RyeQ0KwqAgwqBlc3RhYmxpc2hlZCBi eSB0aGlzIHNwZWNpZmljYXRpb24uDQpUaGlzIHNlY3Rpb24gc2VlbXMgbGlrZSBpdCBuZWVkcyBS RkMyMTE5IGxhbmd1YWdlDQoNCk1pa2U+IFRoaXMgcmVnaXN0cnkgbGFuZ3VhZ2UgY2xvc2VseSBm b2xsb3dzIHRoYXQgaW4gT0F1dGggMi4wIFtSRkMgNjc0OV0gYW5kIHN1YnNlcXVlbnQgT0F1dGgg c3BlY2lmaWNhdGlvbnMuICBJJ2QgcmF0aGVyIGtlZXAgdGhlbSBwYXJhbGxlbCB1bmxlc3Mgc29t ZXRoaW5nIGlzbid0IGNsZWFyLg0KDQpMaW5lIDU2OA0KwqAgwqBWYWx1ZXMgYXJlIHJlZ2lzdGVy ZWQgb24gYSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIFtSRkM1MjI2XSBiYXNpcw0KwqAgwqBhZnRl ciBhIHR3by13ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlIG1haWx0bzpvYXV0aC1leHQtcmV2aWV3 QGlldGYub3JnDQrCoCDCoG1haWxpbmcgbGlzdCwgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9y ZSBEZXNpZ25hdGVkIEV4cGVydHMuDQpXaGF0IGhhcHBlbnMgaWYgeW91IGRvbid0IGRvIGFueXRo aW5nIHdpdGhpbiB0d28gd2Vla3MuDQoNCkFzIGl0IHNheXMgbGF0ZXIgaW4gdGhpcyBzZWN0aW9u ICJSZWdpc3RyYXRpb24gcmVxdWVzdHMgdGhhdCBhcmUgdW5kZXRlcm1pbmVkIGZvciBhIHBlcmlv ZCBsb25nZXIgdGhhbiAyMSBkYXlzIGNhbiBiZSBicm91Z2h0IHRvIHRoZSBJRVNHJ3MgYXR0ZW50 aW9uICh1c2luZyB0aGUgaWVzZ0BpZXRmLm9yZyBtYWlsaW5nIGxpc3QpIGZvciByZXNvbHV0aW9u LiIgIA0KDQpMaW5lIDc1Ng0KwqAgwqBvIMKgQ2hhbmdlIENvbnRyb2xsZXI6IElFU0cNCsKgIMKg byDCoFNwZWNpZmljYXRpb24gRG9jdW1lbnQocyk6IFNlY3Rpb24gMiBvZiBbWyB0aGlzIHNwZWNp ZmljYXRpb24gXV0NCkV4dHJhIHdoaXRlc3BhY2UuDQoNCkFyZSB5b3UgdGFsa2luZyBhYm91dCB0 aGVyZSBiZWluZyB0d28gc3BhY2VzIGJldHdlZW4gdGhlIGJ1bGxldCBjaGFyYWN0ZXIgIm8iIGFu ZCB0aGUgaXRlbXMgc3VjaCBhcyAiQ2hhbmdlIENvbnRyb2xsZXI6IElFU0ciPyAgVGhhdCdzIHdo YXQgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPiBkb2VzLiAgT3IgYXJlIHlvdSB3YW50aW5nIG1vcmUg d2hpdGVzcGFjZSBzb21ld2hlcmU/ICBQbGVhc2UgZ2l2ZSBtb3JlIGNvbnRleHQgYmVjYXVzZSBJ J20gbm90IGxvb2tpbmcgYXQgdGhpcyBvbiBQaGFicmljYXRvci4gIChJIGNyZWF0ZWQgYW4gYWNj b3VudCAibWJqIiBidXQgaXQgd2FudGVkIG1lIHRvIGluc3RhbGwgYSBzZWNvbmQgZmFjdG9yIHBo b25lIGFwcCwgd2hpY2ggc2VlbWVkIGxpa2UgYSBiaXQgbXVjaC4uLikNCg0KCQkJCVRoYW5rcywN CgkJCQktLSBNaWtlDQo= From nobody Thu Sep 7 13:11:35 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E545120720 for ; Thu, 7 Sep 2017 13:11:33 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 aZ7zhswghkAH for ; Thu, 7 Sep 2017 13:11:31 -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 57D1A132FB1 for ; Thu, 7 Sep 2017 13:11:30 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id y29so360667pff.0 for ; Thu, 07 Sep 2017 13:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=B9dW/7WJ+zm4+8VagwFN4rLPilWKbCBOvSJFNDYsGns=; b=mr6vFXW4fWN6jc1WoDAX1vh141K8UOBz9so7pW6jE7t+ysvKW1BW2l5fC05jVQ/bEx q6C1L9oQV9IvIwfPVI/1A9YOGt0tgFRu9JetOrbiB/4NH8cP7pW4DaTlei7xJ26/pUng 20pfqATFRkYQ1emFZg84ia0HSAqaFxnAKLJeXeYFGVZW+VBYw+RWIsOuaDa5yIO+qVgM pcRCrwxaPKnfcqERDhWBSGJFqdQSbOchsCCVQpOJAnWIKtL3xzwc0XOvpMeRDkvKVjS4 I5uMTGJImdFsqVIfDl3htqUPG18xxSyLLg8RohjwzA7RBc/GR7mNVkLKiYJncjgMAYcF bccw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=B9dW/7WJ+zm4+8VagwFN4rLPilWKbCBOvSJFNDYsGns=; b=CO3WCsb3mW+76BSeLA6jbm/Zj9RHHtB54p2d+7uD3WbvlvaTOz6bJbfBucAJaDy8NL jI7hefkvnsWc8XhJu8SbKfnuzvl5ndZ4p69+u8Jcf0N/ieky6GVK+be6aGOADhkjNz95 ois+waHukr4Yj9CNG4K91GYPUIcf/E/QHfpjjps40SuCAd27m9S3dUUGgOmC/OUXV7ZB aviJzArkzTi3eX/h8Cko+xRGBM8RW/3LrGnKOVZTZ8YAsLmgYKerY70TQNsx6wnOb8Xw MVSobByK1XuoWS9bet1CR/LiW6+kJW6FD+PvMyzbAP+i31OrsryD2iKuYZSwLhiOtEHn kuYw== X-Gm-Message-State: AHPjjUg7mgXWoMtjCxZLJc/7nzCmpr/uhao5DrJIn/WBSqZTF9CesnVr 04thfgWmzsPzl2w0liwvsSucoXEJyTm0u9xc5QSgpUef5KY= X-Google-Smtp-Source: ADKCNb4zo/zx47DnlYDIEuUP6RGjTEAc6YnRu0Qobi+3XP0FijtqMWIF4+OkNvDWx73aEGBRfhGXP4ecVMnD88Y9itg= X-Received: by 10.99.55.2 with SMTP id e2mr583406pga.226.1504815090483; Thu, 07 Sep 2017 13:11:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.15 with HTTP; Thu, 7 Sep 2017 13:11:29 -0700 (PDT) From: Samuel Erdtman Date: Thu, 7 Sep 2017 22:11:29 +0200 Message-ID: To: draft-ietf-oauth-device-flow.authors@ietf.org Cc: "" Content-Type: multipart/alternative; boundary="94eb2c003a2aebd95505589f10ac" Archived-At: Subject: [OAUTH-WG] Review of draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 20:11:33 -0000 --94eb2c003a2aebd95505589f10ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Authors Thanks for writing this very useful draft. I have some review comments that I hope will be useful. As a general comment, has it been considered to include CoAP mappings too? it might be good to reach even more constrained devices (maybe another draft). 1. Introduction Missing newline between Step E and D 1. Introduction The bullet list with the polling of the client and the user authorisation is a bit hard to read, step D comes again after E. Maybe it would be easier to read if using decimal numbers. =E2=80=981. Introduction=E2=80=99 and =E2=80=983. Protocol=E2=80=99 I would like to move the ascii art and the corresponding list of steps from =E2=80=981. Introduction=E2=80=99 to =E2=80=983. Protocol=E2=80=99 and us= e the terminology explained in =E2=80=982. Terminology=E2=80=99 3.1. Device Authorization Request Is there no authentication? e.g. use of client secret? (or Pre-Shared Key or Raw Public key as described in draft-erdtman-ace-rpcc) I don=E2=80=99t think client identification is enough I think it should authenticate, at least as the recommendation. 3.2. Device Authorization Response I would like to change verification_uri be optional. If for example the device vendor has a companion app that app could easily have the verification_uri, that would simplify for the user that would only have to enter the code. (and it could save some bytes). 3.2. Device Authorization Response I think it would make sense to add an optional parameter with the token endpoint uri, in that way it does not have to be hardcoded in the client (or discovered) but the AS can tell the client where to get the token. Or it could be done with a redirect to the token URL or the Device Verification Code could be a the URL to poll instead. 3.4. Device Access Token Request client_id, it says REQUIRED but then it states that it is to be used only if =E2=80=9Cclient is not authenticating with the authorization server as d= escribed in Section 3.2.1. of [RFC6749].=E2=80=9D I think the parameter should be optional and authentication required. 3.2. Device Authorization Response and 3.5. Device Access Token Response =E2=80=9CThe interval at which the client polls MUST NOT be more frequent t= han the "interval" parameter returned in the Device Authorization Response (see Section 3.2).=E2=80=9D =E2=80=9COPTIONAL. The minimum amount of time in seconds that the client SHOULD wait between polling requests to the token endpoint.=E2=80=9D Feels like a contradiction between the parameter description and token endpoint response. I would like to have MUST in both cases. 3.5. Device Access Token Response I think last paragraph is better suited in the introduction section. 5.2. Device Trustworthiness I think device authentication should/could be mentioned here --94eb2c003a2aebd95505589f10ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Authors

Thanks for writing = this very useful draft.

I have some review comments that I hop= e will be useful.

As a general comment, has it been considered= to include CoAP mappings too? it might be good to reach even more constrai= ned devices (maybe another draft).


1.=C2=A0 Introduction
Miss= ing newline between Step E and D

1.=C2=A0 Introduction
The bullet= list with the polling of the client and the user authorisation is a bit ha= rd to read, step D comes again after E. Maybe it would be easier to read if= using decimal numbers.

=E2=80=981.=C2=A0 Introduction=E2=80=99 and = =E2=80=983.=C2=A0 Protocol=E2=80=99
I would like to move the ascii art a= nd the corresponding list of steps from =E2=80=981.=C2=A0 Introduction=E2= =80=99 to =E2=80=983.=C2=A0 Protocol=E2=80=99 and use the terminology expla= ined in =E2=80=982.=C2=A0 Terminology=E2=80=99

3.1.=C2=A0 Device Aut= horization Request
Is there no authentication? e.g. use of client secret= ? (or Pre-Shared Key or Raw Public key as described in draft-erdtman-ace-rp= cc)
I don=E2=80=99t think client identification is enough I think it sho= uld authenticate, at least as the recommendation.

3.2.=C2=A0 Device = Authorization Response
I would like to change verification_uri be option= al. If for example the device vendor has a companion app that app could eas= ily have the verification_uri, that would simplify for the user that would = only have to enter the code. (and it could save some bytes).

3.2.=C2= =A0 Device Authorization Response
I think it would make sense to add an = optional parameter with the token endpoint uri, in that way it does not hav= e to be hardcoded in the client (or discovered) but the AS can tell the cli= ent where to get the token. Or it could be done with a redirect to the toke= n URL or the Device Verification Code could be a the URL to poll instead.
3.4.=C2=A0 Device Access Token Request
client_id, it says REQUIRED= but then it states that it is to be used only if =E2=80=9Cclient is not au= thenticating with the authorization server as described in Section 3.2.1. o= f [RFC6749].=E2=80=9D
I think the parameter should be optional and authe= ntication required.

3.2.=C2=A0 Device Authorization Response and=C2= =A0 3.5.=C2=A0 Device Access Token Response
=E2=80=9CThe interval at whi= ch the client polls MUST NOT be more frequent than
=C2=A0=C2=A0 the &quo= t;interval" parameter returned in the Device Authorization
=C2=A0= =C2=A0 Response (see Section 3.2).=E2=80=9D
=E2=80=9COPTIONAL.=C2=A0 The= minimum amount of time in seconds that the client
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 SHOULD wait between polling requests to the token endpoint.=E2=80= =9D
Feels like a contradiction between the parameter description and tok= en endpoint response. I would like to have MUST in both cases.

3.5.= =C2=A0 Device Access Token Response
I think last paragraph is better sui= ted in the introduction section.

5.2.=C2=A0 Device TrustworthinessI think device authentication should/could be mentioned here


<= br>



--94eb2c003a2aebd95505589f10ac-- From nobody Thu Sep 7 14:20:07 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F03132F60; Thu, 7 Sep 2017 14:20:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150481920641.7990.15935311726484722083@ietfa.amsl.com> Date: Thu, 07 Sep 2017 14:20:06 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 21:20:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Authorization Server Metadata Authors : Michael B. Jones Nat Sakimura John Bradley Filename : draft-ietf-oauth-discovery-07.txt Pages : 23 Date : 2017-09-07 Abstract: This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-discovery-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 7 14:24:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2523D132F60 for ; Thu, 7 Sep 2017 14:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 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_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9uWNycpr-vF for ; Thu, 7 Sep 2017 14:24:02 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0095.outbound.protection.outlook.com [104.47.32.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11DD132F5C for ; Thu, 7 Sep 2017 14:24:02 -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=pqWTmwUrzH3PGuyN07HzT6TlDW6DgL+1B8GPzgfXA7A=; b=JQSn6p3nWC3MVsvPfOVsGS9LgLlGaCnGqEZqtuPqWr+TKjjnF3bF8mAmA0Ri4WU3BEOT/SvxmTPJl0RFM0k7IGlGBrxUpuLEGUfJjjwTyJsT8ZUjuOhYPYpXGvoiUPc4qAnvVhA90QPMtbIlOu8AMgrAZQmzGFC/BoD/IjMjtkc= Received: from BN6PR21MB0500.namprd21.prod.outlook.com (10.172.112.10) by BN6PR21MB0689.namprd21.prod.outlook.com (10.175.131.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.56.5; Thu, 7 Sep 2017 21:24:01 +0000 Received: from BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) by BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) with mapi id 15.20.0056.003; Thu, 7 Sep 2017 21:24:01 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Authorization Server Metadata spec incorporating Area Director feedback Thread-Index: AdMoHZsLLZcBirD6T6uXTrkYkOpqCg== Date: Thu, 7 Sep 2017 21:24:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-09-07T14:23:59.4694786-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:8::548] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0689; 6:b7f7rqveaxzqQhWEL5M0tctNYdZdkzci2BPms1TXcgiatz/h8gCUYN+tS4upIiy4Cp6HSl0PVohVMWjroKxisXzPdAvk4NYyMLydf3+ld81gAliR4dnDN6m2g5yVaoK8td/NAKiYAAoOZb1ZKG23lqXYh7VH52fbIlI3R1LF3qi9+s9o3qPjXcmvdnaIcIQh/9UXt8ooODQVVr4PodlpF0eDt6zgAf3fJnjvQZ+pSnwvnzntoEQAjFMAkiYNfyHLg3Y8xtBlhhDfgwvEpykf0m7O0QRda878D3fFblqzl+P4YvCE/ipCCs2WCjTKAOdsr421FR5ufVoN19kA/Y0rgg==; 5:cdCvwtsl+smrstuw7N+W+zDj7P25Uq0NenxfSwb58V+g4a8nzD2F52lqLe32zR2SA/W1xs/kZ1MDb8LeljO+Zgsd4zTRAlTEfWSox4t68771FwG2f8dA4huabAiOd76KVuk+ECbmJxKa5Rmfl3aeUA==; 24:/XFmB3eI+r8R15j68irje2sIlebAF5LoMWa/TT2VDasDDSw4gGgub8fs6eJ41up4JB6SDputiLZWOM9TiksEoAwwdZJ8WlqpCAzdd0obMXE=; 7:qTBW1xBQgUvWriDIjy+aQF7Ym997QFx/VaqtGf7+ljXcI73yLf2xPrKt7Ctns36yQlgk28pwo4D8Snd4uQfaK3j5M5WUtmpwF/s6mmE+9aLntBaYH206Dl26/kRamcjpQ+dledSBZvlcj1+B+xPs4RGii+lNAxk1x0S5Q7cEPaMg3gNqQu/xCkHsfslsFFhVDhF1BqeIaz7u/Ry0Std1/mnBbCiJt9Cl8T1PQGYZT90= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c11123b0-6ba8-4afb-c8ac-08d4f636c233 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR21MB0689; x-ms-traffictypediagnostic: BN6PR21MB0689: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(31418570063057)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR21MB0689; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR21MB0689; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(209900001)(47760400005)(189002)(199003)(9686003)(55016002)(68736007)(102836003)(10090500001)(606006)(3280700002)(99286003)(86612001)(5630700001)(86362001)(53376002)(2351001)(14454004)(110136004)(2900100001)(189998001)(22452003)(77096006)(6436002)(2906002)(6116002)(8990500004)(3660700001)(74316002)(6506006)(8936002)(97736004)(25786009)(790700001)(101416001)(5640700003)(50986999)(54356999)(2501003)(6306002)(106356001)(105586002)(236005)(54896002)(6916009)(4326008)(478600001)(53936002)(10290500003)(5660300001)(7736002)(7696004)(8676002)(966005)(33656002)(1730700003)(81156014)(81166006)(72206003)(6606295002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0689; H:BN6PR21MB0500.namprd21.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_BN6PR21MB0500E5B00554234ED0597DE6F5940BN6PR21MB0500namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 21:24:01.0941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0689 Archived-At: Subject: [OAUTH-WG] OAuth Authorization Server Metadata spec incorporating Area Director feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 21:24:05 -0000 --_000_BN6PR21MB0500E5B00554234ED0597DE6F5940BN6PR21MB0500namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth Authorization Server Metadata specification has been updated to i= ncorporate feedback from Security Area Director Eric Rescorla. Thanks to E= KR for his useful review. A number of defaults and restrictions are now be= tter specified. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-discovery-07.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1731 and = as @selfissued. --_000_BN6PR21MB0500E5B00554234ED0597DE6F5940BN6PR21MB0500namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth Authorization Server Metadata specificatio= n has been updated to incorporate feedback from Security Area Director Eric= Rescorla.  Thanks to EKR for his useful review.  A number of def= aults and restrictions are now better specified.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

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

 

--_000_BN6PR21MB0500E5B00554234ED0597DE6F5940BN6PR21MB0500namp_-- From nobody Thu Sep 7 14:25:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19408132F60 for ; Thu, 7 Sep 2017 14:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSQvIZvFHzt6 for ; Thu, 7 Sep 2017 14:25:18 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0131.outbound.protection.outlook.com [104.47.32.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD07132F52 for ; Thu, 7 Sep 2017 14:25:18 -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=7vZgAsGa5HXCwKLTW0T3qDnYr1I2eDIvBK91YUi3Qqk=; b=UAk4ruzYhO1aRTK48vvjdgJyBn+xMOY0PW4hEZ/wmIum+cjTxNCrSEOxfInZH7mp6nbSvvgzYpj1C3+UH/b0tcPYze1f4VDKXnH2Dv0dvw2INo8PGBrwWVLiH6FsBgD7xHyTzhcXvwH8RSJ9Ec0zkT1iQu/8jJ5jvcfbpY/ySfw= Received: from BN6PR21MB0500.namprd21.prod.outlook.com (10.172.112.10) by BN6PR21MB0467.namprd21.prod.outlook.com (10.172.111.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.56.0; Thu, 7 Sep 2017 21:25:17 +0000 Received: from BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) by BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) with mapi id 15.20.0056.003; Thu, 7 Sep 2017 21:25:17 +0000 From: Mike Jones To: Eric Rescorla , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 Thread-Index: AQHTJQPOGSEV1sPnL0a/osPnuKlQ5aKm2zkwgAMD8+A= Date: Thu, 7 Sep 2017 21:25:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-09-05T16:11:52.0851161-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:8::548] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0467; 6:k+2LFzGOFKYc6QentomdS499Po+bFy88rYXUdp5TFhtOLN88QiLv1J4Gc9lgsSjmBEBQlcQMh3ePi4myNoIyIb9buZMsVDXTtYT9OS+PircRGoA9TsIETluFr+13SD81EhOthDOfkP6jZ04rIdYsbcm3tfuqVyJXyy5IMvy5vrbhwg6LummnZ78ax7TCJU90HOegHTfQxsZBXyIUBhwnxH5ezFg0XDOFZVikNU6o7LmendiIBmC5rR8sd5AZzxopFao9LPZi/D03/B8W2rC96bq4Gbi6UDXfgbXPS4bndb782MREh0487L2fHTBAuvJLonMQ4zg85LLYaxRvxknXzA==; 5:C2jb3nMt/1oaFfHBEKf9DcTYKbLyM/EyVwYECuOfwZdkxdOZT3PaUXRS4MT5wTpds3K954lXvllGV8lCNj7EG9E9bIAqSeIolhjxe0/FfhWsjx9mXx3QQ1DlaSgoBqY2OCeIUElOHhjmhvnVfgbulg==; 24:/JRdPj2xiVcgjkPYIXoIFm1aEbCS2lbAzFzABsP5BwB9h5zHDtJFekIoxXSGNH/iajUhKKboRlGvmk3YDmtRy7tcTWHmJymkZpFeGSjVBoQ=; 7:XwwVkhC41jDULZB3ezHs+yVzPId3XFxtVylW2ewINiWiDyKXV3aReKVnrSGMYI/wnS3PF3ZrpMEPr94CXWj+IQphg4oVY5JZoL/QlQNShlTJagVrldLkJ7SxzioC95Bxsz049C/97Fev5U0lkB6JSltZtK1R++MgNqfWb8VaAdSiFoB/0tpG9WgnfNKTElgZlhSf61nOqlHl7fz0ITbpKj/NsCln6NRwyjprx/R5Kog= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d0b590c9-ca0e-49b8-e1f5-08d4f636ef65 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR21MB0467; x-ms-traffictypediagnostic: BN6PR21MB0467: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR21MB0467; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR21MB0467; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(189002)(199003)(13464003)(377454003)(2950100002)(81166006)(81156014)(3280700002)(55016002)(6306002)(102836003)(99286003)(230783001)(7696004)(10090500001)(3660700001)(6246003)(478600001)(72206003)(97736004)(305945005)(50986999)(10290500003)(86362001)(74316002)(6116002)(53546010)(7736002)(54356999)(8990500004)(966005)(25786009)(8676002)(101416001)(8936002)(189998001)(76176999)(6506006)(6436002)(77096006)(2900100001)(2501003)(86612001)(229853002)(33656002)(14454004)(2906002)(68736007)(53936002)(5660300001)(105586002)(9686003)(22452003)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0467; H:BN6PR21MB0500.namprd21.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 21:25:16.9559 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0467 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 21:25:21 -0000 RHJhZnQgLTA3IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRp c2NvdmVyeS0wNyBjb250YWlucyB0aGVzZSBwcm9wb3NlZCByZXNvbHV0aW9ucy4gIFRoZSBvbmx5 IGNoYW5nZSBpcyB0aGF0IGluIHBsYWNlcyB3aGVyZSBJJ2QgcHJldmlvdXNseSBwcm9wb3NlZCB0 byBzYXkgIklmIG9taXR0ZWQsIHRoZXNlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgY2Fubm90IGJl IHVzZWQiIEkgbm93IHNheSAiVGhpcyBtZXRhZGF0YSBlbnRyeSBNVVNUIGJlIHByZXNlbnQgaWYg ZWl0aGVyIG9mIHRoZXNlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgYXJlIHNwZWNpZmllZCBpbiB0 aGUgInt0b2tlbixyZXZvY2F0aW9uLGludHJvc3BlY3Rpb259X2VuZHBvaW50X2F1dGhfbWV0aG9k c19zdXBwb3J0ZWQiIGVudHJ5LiAgTm8gZGVmYXVsdCBhbGdvcml0aG1zIGFyZSBpbXBsaWVkIGlm IHRoaXMgZW50cnkgaXMgb21pdHRlZC4iDQoNCkkgbWFkZSB0aGUgY2hhbmdlIGJlY2F1c2Ugc2F5 aW5nIHRoYXQgdGhleSBjYW5ub3QgYmUgdXNlZCBpc24ndCBhY3R1YWxseSBjb3JyZWN0LiAgVGhp cyBpbmZvcm1hdGlvbiBjb3VsZCBhbHdheXMgaGF2ZSBiZWVuIGNvbW11bmljYXRlZCBvdXQtb2Yt YmFuZCB0byB0aGUgbWV0YWRhdGEuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBNaWtlIEpvbmVzIA0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDUs IDIwMTcgNDoxMiBQTQ0KVG86ICdFcmljIFJlc2NvcmxhJyA8ZWtyQHJ0Zm0uY29tPjsgb2F1dGhA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIEFEIFJldmlldzogZHJhZnQtaWV0Zi1v YXV0aC1kaXNjb3ZlcnktMDYNCg0KVGhhbmtzIGZvciB5b3VyIHVzZWZ1bCByZXZpZXcsIEVyaWMu ICBQcm9wb3NlZCByZXNvbHV0aW9ucyB0byBhbGwgY29tbWVudHMgYXJlIGlubGluZSBwcmVmaXhl ZCBieSAiTWlrZT4iLg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBTdW5kYXksIFNlcHRlbWJlciAz LCAyMDE3IDM6MjYgUE0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdHXSBB RCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA2DQoNCkhpIGZvbGtzLA0KDQpO b3RlOiB0aGUgb3JpZ2luYWwgb2YgdGhpcyByZXZpZXcgaXMgb24gUGhhYnJpY2F0b3IgYXQ6DQoN CsKgIGh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q3DQoNCklmIHlv dSB3YW50IHRvIHNlZSBjb21tZW50cyBpbiBjb250ZXh0LCB5b3UgY2FuIGdvIHRoZXJlLiBBbHNv LCB5b3UgY2FuIGNyZWF0ZSBhbiBhY2NvdW50IGFuZCByZXNwb25kIGlubGluZSBpZiB5b3UgbGlr ZS4NCklmIHlvdSBlbGVjdCB0bywgbGV0IG1lIGtub3cgaWYgeW91IHJ1biBpbnRvIHByb2JsZW1z Lg0KDQotRWtyDQoNCg0KSSBoYXZlIG1hcmtlZCBhIG51bWJlciBvZiBwbGFjZXMgd2hlcmUgaXQg c2VlbXMgbGlrZSB5b3UgZWl0aGVyIG5lZWQgZGVmYXVsdHMgb3IgbmVlZCB0byBpbmRpY2F0ZSB3 aGF0IHRoZSBzZW1hbnRpY3MgYXJlIGlmIG1pc3NpbmcNCg0KDQrCoCDCoFRoaXMgbWV0YWRhdGEg Y2FuIGVpdGhlciBiZSBjb21tdW5pY2F0ZWQgaW4gYSBzZWxmLWFzc2VydGVkIGZhc2hpb24NCsKg IMKgb3IgYXMgYSBzZXQgb2Ygc2lnbmVkIG1ldGFkYXRhIHZhbHVlcyByZXByZXNlbnRlZCBhcyBj bGFpbXMgaW4gYSBKU09OIEkgYXNzdW1lICJzZWxmLWFzc2VydGVkIiBpbiB0aGlzIGNhc2UgbWVh bnMgImFzc2VydGVkIGJ5IHRoZSBzZXJ2ZXIgb3JpZ2luIHZpYSBIVFRQUyINCg0KTWlrZT4gVGhh bmtzIC0gSSB3aWxsIHVzZSB0aGlzIGxhbmd1YWdlLg0KDQpMaW5lIDIyMg0KwqAgwqAgwqAgYXV0 aGVudGljYXRpb24gbWV0aG9kcy7CoCBTZXJ2ZXJzIFNIT1VMRCBzdXBwb3J0ICJSUzI1NiIuwqAg VGhlDQrCoCDCoCDCoCB2YWx1ZSAibm9uZSIgTVVTVCBOT1QgYmUgdXNlZC4NCldoYXQncyB0aGUg ZGVmYXVsdCBpZiBvbWl0dGVkPw0KDQpNaWtlPiBJIHdpbGwgYWRkICJJZiBvbWl0dGVkLCB0aGVz ZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGNhbm5vdCBiZSB1c2VkLiINCg0KTGluZSAyMzUNCsKg IMKgIMKgIHJlcHJlc2VudGVkIGFzIGEgSlNPTiBhcnJheSBvZiBCQ1A0NyBbUkZDNTY0Nl0gbGFu Z3VhZ2UgdGFnDQrCoCDCoCDCoCB2YWx1ZXMuDQpXaGF0J3MgdGhlIGRlZmF1bHQgaWYgb21pdHRl ZD8NCg0KTWlrZT4gVGhlcmUgaXMgbm8gZGVmYXVsdC4gIEkgd2lsbCBhZGQgIklmIG9taXR0ZWQs IHRoZSBzZXQgb2Ygc3VwcG9ydGVkIGxhbmd1YWdlcyBhbmQgc2NyaXB0cyBpcyB1bnNwZWNpZmll ZC4iDQoNCkxpbmUgMjY3DQrCoCDCoCDCoCAiT0F1dGggVG9rZW4gRW5kcG9pbnQgQXV0aGVudGlj YXRpb24gTWV0aG9kcyIgcmVnaXN0cnkNCsKgIMKgIMKgIFtJQU5BLk9BdXRoLlBhcmFtZXRlcnNd Lg0KV2hhdCdzIHRoZSBkZWZhdWx0IGlmIG9taXR0ZWQ/DQoNCk1pa2U+IEkgd2lsbCBhZGQgY2xp ZW50X3NlY3JldF9iYXNpYyBhcyB0aGUgZGVmYXVsdCAtIGp1c3QgbGlrZSBpdCBhbHJlYWR5IHdh cyBmb3IgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZC4NCg0KTGluZSAyNzUN CsKgIMKgIMKgICJjbGllbnRfc2VjcmV0X2p3dCIgYXV0aGVudGljYXRpb24gbWV0aG9kcy7CoCBU aGUgdmFsdWUgIm5vbmUiIE1VU1QNCsKgIMKgIMKgIE5PVCBiZSB1c2VkLg0KV2hhdCdzIHRoZSBk ZWZhdWx0IGlmIG9taXR0ZWQ/DQoNCk1pa2U+IEkgd2lsbCBhZGQgIklmIG9taXR0ZWQsIHRoZXNl IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgY2Fubm90IGJlIHVzZWQuIg0KDQpMaW5lIDI4OA0KwqAg wqAgwqAgQWNjZXNzIFRva2VuIFR5cGVzIiByZWdpc3RyeSBbSUFOQS5PQXV0aC5QYXJhbWV0ZXJz XS4gwqAoVGhlc2UNCsKgIMKgIMKgIHZhbHVlcyBhcmUgYW5kIHdpbGwgcmVtYWluIGRpc3RpbmN0 LCBkdWUgdG8gU2VjdGlvbiA3LjIuKSBXaGF0J3MgdGhlIGRlZmF1bHQgaWYgb21pdHRlZD8NCg0K TWlrZT4gVGhlcmUgaXMgbm8gb2J2aW91cyBkZWZhdWx0LiAgVGhlcmVmb3JlLCBJIHdpbGwgYWRk ICJJZiBvbWl0dGVkLCB0aGUgc2V0IG9mIHN1cHBvcnRlZCBhdXRoZW50aWNhdGlvbiBtZXRob2Rz IE1VU1QgYmUgZGV0ZXJtaW5lZCBieSBvdGhlciBtZWFucy4iDQoNCkxpbmUgMjk2DQrCoCDCoCDC oCAiY2xpZW50X3NlY3JldF9qd3QiIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuwqAgVGhlIHZhbHVl ICJub25lIiBNVVNUDQrCoCDCoCDCoCBOT1QgYmUgdXNlZC4NCldoYXQncyB0aGUgZGVmYXVsdCBp ZiBvbWl0dGVkPw0KDQpNaWtlPiBJIHdpbGwgYWRkICJJZiBvbWl0dGVkLCB0aGVzZSBhdXRoZW50 aWNhdGlvbiBtZXRob2RzIGNhbm5vdCBiZSB1c2VkLiINCg0KTGluZSAzMDQNCsKgIMKgIMKgIGNo YWxsZW5nZSBtZXRob2QgdmFsdWVzIGFyZSB0aG9zZSByZWdpc3RlcmVkIGluIHRoZSBJQU5BICJQ S0NFDQrCoCDCoCDCoCBDb2RlIENoYWxsZW5nZSBNZXRob2RzIiByZWdpc3RyeSBbSUFOQS5PQXV0 aC5QYXJhbWV0ZXJzXS4NCldoYXQncyB0aGUgZGVmYXVsdCBpZiBvbWl0dGVkPw0KDQpNaWtlPiBJ IHdpbGwgYWRkICJJZiBvbWl0dGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3Qg c3VwcG9ydCBQS0NFLiINCg0KTGluZSAzNDMNCsKgIMKgTVVTVCBiZSByZWdpc3RlcmVkIGluIHRo ZSBJQU5BICJXZWxsLUtub3duIFVSSXMiIHJlZ2lzdHJ5DQrCoCDCoFtJQU5BLndlbGwta25vd25d Lg0KSU1QT1JUQU5UOiBTaG91bGRuJ3QgdGhpcyBiZSByZXF1aXJlZCB0byBiZSBIVFRQUw0KDQpN aWtlPiBJIHdpbGwgYWRkICJUaGlzIHBhdGggTVVTVCB1c2UgdGhlICJodHRwcyIgc2NoZW1lLiIN Cg0KTGluZSA1MDANCsKgIMKgY2xpZW50IE1VU1QgcGVyZm9ybSBhIFRMUy9TU0wgc2VydmVyIGNl cnRpZmljYXRlIGNoZWNrLCBwZXIgUkZDIDYxMjUNCsKgIMKgW1JGQzYxMjVdLsKgIEltcGxlbWVu dGF0aW9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGNhbiBiZSBmb3VuZCBpbg0KwqAgwqBSZWNv bW1lbmRhdGlvbnMgZm9yIFNlY3VyZSBVc2Ugb2YgVExTIGFuZCBEVExTIFtCQ1AxOTVdLg0KSG1t Li4uLiBJJ20gdW5zdXJlIGFib3V0IHdoZXRoZXIgdGhpcyBzaG91bGQgYmUgYSBjaXRhdGlvbiB0 byAyODE4LiBJcyB0aGUgZ2VuZXJhbCBmZWVsaW5nIHRoYXQgNjEyNSBzdXBlcmNlZGVkIDI4MTg/ DQoNCk1pa2U+IE9BdXRoIDIuMCBbUkZDIDY3NDldIGFsc28gcmVxdWlyZXMgYW4gUkZDIDYxMjUg Y2VydGlmaWNhdGUgdmFsaWRhdGlvbiwgc28gdGhpcyBpcyBpbiBsaW5lIHdpdGggb3RoZXIgdXNl cyBvZiB0aGUgT0F1dGggcHJvdG9jb2wgZmFtaWx5Lg0KDQpMaW5lIDU2NA0KwqAgwqBUaGUgZm9s bG93aW5nIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmUgaXMgdXNlZCBmb3IgdGhlIHJlZ2lzdHJ5DQrC oCDCoGVzdGFibGlzaGVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbi4NClRoaXMgc2VjdGlvbiBzZWVt cyBsaWtlIGl0IG5lZWRzIFJGQzIxMTkgbGFuZ3VhZ2UNCg0KTWlrZT4gVGhpcyByZWdpc3RyeSBs YW5ndWFnZSBjbG9zZWx5IGZvbGxvd3MgdGhhdCBpbiBPQXV0aCAyLjAgW1JGQyA2NzQ5XSBhbmQg c3Vic2VxdWVudCBPQXV0aCBzcGVjaWZpY2F0aW9ucy4gIEknZCByYXRoZXIga2VlcCB0aGVtIHBh cmFsbGVsIHVubGVzcyBzb21ldGhpbmcgaXNuJ3QgY2xlYXIuDQoNCkxpbmUgNTY4DQrCoCDCoFZh bHVlcyBhcmUgcmVnaXN0ZXJlZCBvbiBhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgW1JGQzUyMjZd IGJhc2lzDQrCoCDCoGFmdGVyIGEgdHdvLXdlZWsgcmV2aWV3IHBlcmlvZCBvbiB0aGUgbWFpbHRv Om9hdXRoLWV4dC1yZXZpZXdAaWV0Zi5vcmcNCsKgIMKgbWFpbGluZyBsaXN0LCBvbiB0aGUgYWR2 aWNlIG9mIG9uZSBvciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0cy4NCldoYXQgaGFwcGVucyBpZiB5 b3UgZG9uJ3QgZG8gYW55dGhpbmcgd2l0aGluIHR3byB3ZWVrcy4NCg0KQXMgaXQgc2F5cyBsYXRl ciBpbiB0aGlzIHNlY3Rpb24gIlJlZ2lzdHJhdGlvbiByZXF1ZXN0cyB0aGF0IGFyZSB1bmRldGVy bWluZWQgZm9yIGEgcGVyaW9kIGxvbmdlciB0aGFuIDIxIGRheXMgY2FuIGJlIGJyb3VnaHQgdG8g dGhlIElFU0cncyBhdHRlbnRpb24gKHVzaW5nIHRoZSBpZXNnQGlldGYub3JnIG1haWxpbmcgbGlz dCkgZm9yIHJlc29sdXRpb24uIiAgDQoNCkxpbmUgNzU2DQrCoCDCoG8gwqBDaGFuZ2UgQ29udHJv bGxlcjogSUVTRw0KwqAgwqBvIMKgU3BlY2lmaWNhdGlvbiBEb2N1bWVudChzKTogU2VjdGlvbiAy IG9mIFtbIHRoaXMgc3BlY2lmaWNhdGlvbiBdXSBFeHRyYSB3aGl0ZXNwYWNlLg0KDQpBcmUgeW91 IHRhbGtpbmcgYWJvdXQgdGhlcmUgYmVpbmcgdHdvIHNwYWNlcyBiZXR3ZWVuIHRoZSBidWxsZXQg Y2hhcmFjdGVyICJvIiBhbmQgdGhlIGl0ZW1zIHN1Y2ggYXMgIkNoYW5nZSBDb250cm9sbGVyOiBJ RVNHIj8gIFRoYXQncyB3aGF0IDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4gZG9lcy4gIE9yIGFyZSB5 b3Ugd2FudGluZyBtb3JlIHdoaXRlc3BhY2Ugc29tZXdoZXJlPyAgUGxlYXNlIGdpdmUgbW9yZSBj b250ZXh0IGJlY2F1c2UgSSdtIG5vdCBsb29raW5nIGF0IHRoaXMgb24gUGhhYnJpY2F0b3IuICAo SSBjcmVhdGVkIGFuIGFjY291bnQgIm1iaiIgYnV0IGl0IHdhbnRlZCBtZSB0byBpbnN0YWxsIGEg c2Vjb25kIGZhY3RvciBwaG9uZSBhcHAsIHdoaWNoIHNlZW1lZCBsaWtlIGEgYml0IG11Y2guLi4p DQoNCgkJCQlUaGFua3MsDQoJCQkJLS0gTWlrZQ0K From nobody Sun Sep 10 10:22:57 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBF8132EC7; Sun, 10 Sep 2017 10:22:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150506417592.8167.6075316607963277976@ietfa.amsl.com> Date: Sun, 10 Sep 2017 10:22:55 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 17:22:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth Security Topics Authors : Torsten Lodderstedt John Bradley Andrey Labunets Filename : draft-ietf-oauth-security-topics-03.txt Pages : 27 Date : 2017-09-10 Abstract: This draft gives a comprehensive overview on open OAuth security topics. It is intended to serve as a working document for the OAuth working group to systematically capture and discuss these security topics and respective mitigations and eventually recommend best current practice and also OAuth extensions needed to cope with the respective security threats. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 10 10:34:18 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2131C132D6D for ; Sun, 10 Sep 2017 10:34:16 -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 by4pj6zbxApT for ; Sun, 10 Sep 2017 10:34:13 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784B9126B6D for ; Sun, 10 Sep 2017 10:34:13 -0700 (PDT) Received: from [79.218.78.62] (helo=[192.168.71.128]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dr67W-0001DX-Bo for oauth@ietf.org; Sun, 10 Sep 2017 19:34:10 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_95ED295C-8C3D-4F5A-A4C1-46DC78A0635B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 10 Sep 2017 19:34:09 +0200 References: <150506417592.8167.6075316607963277976@ietfa.amsl.com> To: oauth In-Reply-To: <150506417592.8167.6075316607963277976@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 17:34:16 -0000 --Apple-Mail=_95ED295C-8C3D-4F5A-A4C1-46DC78A0635B Content-Type: multipart/alternative; boundary="Apple-Mail=_C27EDB92-4487-4E52-B7AB-2F80F819C10E" --Apple-Mail=_C27EDB92-4487-4E52-B7AB-2F80F819C10E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, the new revision adds an extensive section on access token leakage at = the resource server = (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-4= .4 = ). I tried to incorporate all contributions and feedback given at the = OAuth security workshop and the WG session in Prague. Please give us feedback. kind regards, Torsten. > Am 10.09.2017 um 19:22 schrieb internet-drafts@ietf.org: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : OAuth Security Topics > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Filename : draft-ietf-oauth-security-topics-03.txt > Pages : 27 > Date : 2017-09-10 >=20 > Abstract: > This draft gives a comprehensive overview on open OAuth security > topics. It is intended to serve as a working document for the OAuth > working group to systematically capture and discuss these security > topics and respective mitigations and eventually recommend best > current practice and also OAuth extensions needed to cope with the > respective security threats. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C27EDB92-4487-4E52-B7AB-2F80F819C10E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

the= new revision adds an extensive section on access token leakage at the = resource server (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03= #section-4.4). I tried to incorporate all contributions and feedback = given at the OAuth security workshop and the WG session in = Prague.

Please = give us feedback.

kind regards,
Torsten.

Am 10.09.2017 um 19:22 schrieb internet-drafts@ietf.org:


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

       Title =           : OAuth = Security Topics
=        Authors =         : Torsten Lodderstedt
=             &n= bsp;           &nbs= p;John Bradley
=             &n= bsp;           &nbs= p;Andrey Labunets
Filename =        : = draft-ietf-oauth-security-topics-03.txt
Pages =           : 27
= Date =            : = 2017-09-10

Abstract:
=   This draft gives a comprehensive overview on open OAuth = security
  topics.  It is intended to = serve as a working document for the OAuth
=   working group to systematically capture and discuss these = security
  topics and respective mitigations = and eventually recommend best
  current = practice and also OAuth extensions needed to cope with the
=   respective security threats.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topi= cs/

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

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


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

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

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

= --Apple-Mail=_C27EDB92-4487-4E52-B7AB-2F80F819C10E-- --Apple-Mail=_95ED295C-8C3D-4F5A-A4C1-46DC78A0635B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAx MDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye 12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFb zz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY 17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSR SR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwID AQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPng HgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v Y3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkq hkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9 CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13Ob fpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/Tc TXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmy e3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGw MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0y NTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3Px A3uZ8LQwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcwOTEwMTczNDA5WjAjBgkqhkiG9w0BCQQxFgQUhYm+6UxyR7e1q3eQeilcd5/8yDYw gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBAFNL0XsGMWT580s140CHH4+2I4yyNUB/0dbEDzUwOe+DHn4vCeIgN6D42HRw jZCvOrwFgarQYp4Pghi9lsQXotlL/9n96SSd8vwBemkLK2IJXXCKcyBYIwF9jKVXrYDrM9f6TKwf P3GWeU29xUbL+NLrojhdXQPCMPoO9pjCab4PgjfCagIHn8AH8slmtjebJ1ZZfS/qfI2/0stdXTdn oQDNmrVFMQXvPyO+EdAzj63pAXR5bdxXxZbtHgrEu/ezJrUWVhybK6sE+VTrT1djyEazlfAmMw0O am2wshJWI/HkTjXSThxt7bIRSyM61FiG/3hQ3D8LpWI5cvhcI5EiCQ0AAAAAAAA= --Apple-Mail=_95ED295C-8C3D-4F5A-A4C1-46DC78A0635B-- From nobody Mon Sep 11 04:19:33 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DC133031 for ; Mon, 11 Sep 2017 04:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD8rja8928MC for ; Mon, 11 Sep 2017 04:19:30 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F7D133023 for ; Mon, 11 Sep 2017 04:19:29 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id AA5E1780373 for ; Mon, 11 Sep 2017 13:19:27 +0200 (CEST) To: oauth@ietf.org References: <150506417592.8167.6075316607963277976@ietfa.amsl.com> From: Denis Message-ID: <725ec2e8-1021-d5be-cfff-a3c1a2b90aab@free.fr> Date: Mon, 11 Sep 2017 13:19:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------35CF7DB48BA26DEF1B7C3532" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 11:19:33 -0000 This is a multi-part message in MIME format. --------------35CF7DB48BA26DEF1B7C3532 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Torsten, Hereafter is my feedback. There are related to two separate concerns :     a) the Alice and Bob Collusion attack" (ABC attack), and     b) privacy issues with the audience parameter. *Alice and Bob Collusion attack" (ABC attack)* The text states in section 4.4.1.2 : A typical flow looks like this: 1.The authorization server associates data with the access token, which bind this particular token to a certain client.         The binding can utilize the client identity, but in most cases the AS utilizes key material (or data derived from the         key material) known to the client.  Replace with: 1.The authorization server binds a particular token, either to a public key where the demonstration of the knowledge                 of the corresponding private key will prove possession of the token, or to an unambiguous well-known identity                 of the client. The last sentence of section 4.4.1.2 is : "This document therefore recommends implementors to consider one of TLS-based approaches wherever possible".  Replace this sentence with the following: However, the binding of a public key to a particular token is unable to counter a collusion attack between two clients, like Bob and Alice that may perform an "Alice and Bob Collusion attack" (ABC attack).Even when private keys are protected by secure elements, a client willing to collaborate with another client will be able to perform all the cryptographic computations needed by the other client.This is a concern as soon as an access token does not contain an unambiguous well-known identity of the client, since the other client would take advantage of one or more personal attributes (e.g. over 18) of the first client without that first client being identified. In order to address that case, clients shall use secure elements that have additional functional and security properties and Authorisation Servers shall make sure that secure elements with such properties are being used by clients requesting tokens. At the moment, none of the OAuth RFCs describes such a technique, but a presentation was made at the OAuth workshop in Zürich in July 2017 where two techniques were described. See: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf The binding of an unambiguous well-known identity of the client to a particular token fully identifies the client and thus the concern is to prevent the stealing of the token by an external attacker.In that case, this document recommends implementors to consider one of TLS-based approaches. *Privacy issues with the audience parameter* The text states in section 4.4.1.3 states: The audience can basically be expressed using logical names or physical addresses (like URLs).  Change it into: _Currently,_ the audience can basically be expressed using logical names or physical addresses (like URLs). The text states in section 4.4.1.3 states: Instead of the URL, it is also possible to utilize the fingerprint of the resource server’s X.509 certificate as audience value. This variant would also allow to detect an attempt to spoof the legit resource server’s URL by using a valid TLS certificate obtained from a different CA.It might also be considered a privacy benefit to hide the resource server URL from the authorization server. Change it into: The use of logical names or of physical addresses leads to privacy concerns, since in such a case the Authorisation Server will be able to know exactly where every access token will be used by every client. In order to address this privacy concern, authorization servers should associate an access token with a certain resource server without, in any way, being able to know which resource server is being designated. For Authorisation Servers, the audience value should be or look like a random number. At the moment, none of the OAuth RFCs describes such a technique. However, solving this issue is technically possible in several ways. Instead of a URL, it has been suggested to use the fingerprint of the resource server’s X.509 certificate as audience value. This variant allows to detect an attempt to spoof the legit resource server’s URL by using a valid TLS certificate obtained from a different CA. However, such a variant, by successive trials, might still allow an Authorisation Server to identify the resource servers. Denis > Hi all, > > the new revision adds an extensive section on access token leakage at > the resource server > (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-4.4). > > I tried to incorporate all contributions and feedback given at the > OAuth security workshop and the WG session in Prague. > > Please give us feedback. > > kind regards, > Torsten. > >> Am 10.09.2017 um 19:22 schrieb internet-drafts@ietf.org >> : >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the >> IETF. >> >>        Title           : OAuth Security Topics >>        Authors         : Torsten Lodderstedt >>                          John Bradley >>                          Andrey Labunets >> Filename        : draft-ietf-oauth-security-topics-03.txt >> Pages           : 27 >> Date            : 2017-09-10 >> >> Abstract: >>   This draft gives a comprehensive overview on open OAuth security >>   topics.  It is intended to serve as a working document for the OAuth >>   working group to systematically capture and discuss these security >>   topics and respective mitigations and eventually recommend best >>   current practice and also OAuth extensions needed to cope with the >>   respective security threats. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-03 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------35CF7DB48BA26DEF1B7C3532 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Torsten,

Hereafter is my feedback. There are related to two separate concerns :

    a) the Alice and Bob Collusion attack" (ABC attack), and
    b) privacy issues with the audience parameter.


Alice and Bob Collusion attack" (ABC attack)

The text states in section 4.4.1.2 :

A typical flow looks like this:

   1.  The authorization server associates data with the access token, which bind this particular token to a certain client. 
        The binding can utilize the client identity, but in most cases the AS utilizes key material (or data derived from the
        key material) known to the client.

 Replace with:

           1.  The authorization server binds a particular token, either to a public key where the demonstration of the knowledge
                of the corresponding private key will prove possession of the token, or to an unambiguous well-known identity
                of the client.

The last sentence of section 4.4.1.2 is :

 "This document therefore recommends implementors to consider one of TLS-based approaches wherever possible".

 Replace this sentence with the following:

However, the binding of a public key to a particular token is unable to counter a collusion attack between two clients,
like Bob and Alice that may perform an "Alice and Bob Collusion attack" (ABC attack).  Even when private keys are
protected by secure elements, a client willing to collaborate with another client will be able to perform all the cryptographic
computations needed by the other client.  This is a concern as soon as an access token does not contain an unambiguous
well-known identity of the client, since the other client would take advantage of one or more personal attributes (e.g. over 18)
of the first client without that first client being identified.

In order to address that case, clients shall use secure elements that have additional functional and security properties
and Authorisation Servers shall make sure that secure elements with such properties are being used by clients requesting tokens.

At the moment, none of the OAuth RFCs describes such a technique, but a presentation was made at the OAuth workshop
in Zürich in July 2017 where two techniques were described. 
See: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf

The binding of an unambiguous well-known identity of the client to a particular token fully identifies the client and
thus the concern is to prevent the stealing of the token by an external attacker.  In that case, this document recommends
implementors to consider one of TLS-based approaches.

Privacy issues with the audience parameter

The text states in section 4.4.1.3 states:

The audience can basically be expressed using logical names or physical addresses (like URLs).

 Change it into:

Currently, the audience can basically be expressed using logical names or physical addresses (like URLs).

The text states in section 4.4.1.3 states:

Instead of the URL, it is also possible to utilize the fingerprint of the resource server’s X.509 certificate as audience value. 
This variant would also allow to detect an attempt to spoof the legit resource server’s URL by using a valid TLS certificate
obtained from a different CA.  It might also be considered a privacy benefit to hide the resource server URL from the authorization server.

Change it into:

The use of logical names or of physical addresses leads to privacy concerns, since in such a case the Authorisation Server
will be able to know exactly where every access token will be used by every client.

In order to address this privacy concern, authorization servers should associate an access token with a certain resource server
without, in any way, being able to know which resource server is being designated.  For Authorisation Servers, the audience value
should be or look like a random number.

At the moment, none of the OAuth RFCs describes such a technique. However, solving this issue is technically possible in several ways.

Instead of a URL, it has been suggested to use the fingerprint of the resource server’s X.509 certificate as audience value.  
This variant allows to detect an attempt to spoof the legit resource server’s URL by using a valid TLS certificate obtained from a different CA. 
However, such a variant, by successive trials, might still allow an Authorisation Server to identify the resource servers.


Denis

Hi all,

the new revision adds an extensive section on access token leakage at the resource server (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-4.4).
I tried to incorporate all contributions and feedback given at the OAuth security workshop and the WG session in Prague.

Please give us feedback.

kind regards,
Torsten.

Am 10.09.2017 um 19:22 schrieb internet-drafts@ietf.org:


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

       Title           : OAuth Security Topics
       Authors         : Torsten Lodderstedt
                         John Bradley
                         Andrey Labunets
Filename        : draft-ietf-oauth-security-topics-03.txt
Pages           : 27
Date            : 2017-09-10

Abstract:
  This draft gives a comprehensive overview on open OAuth security
  topics.  It is intended to serve as a working document for the OAuth
  working group to systematically capture and discuss these security
  topics and respective mitigations and eventually recommend best
  current practice and also OAuth extensions needed to cope with the
  respective security threats.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-03


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

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

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



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


--------------35CF7DB48BA26DEF1B7C3532-- From nobody Mon Sep 11 12:36:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B6E1331F2 for ; Mon, 11 Sep 2017 12:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 757ESGxFDZ6N for ; Mon, 11 Sep 2017 12:35:54 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0093.outbound.protection.outlook.com [104.47.36.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591BC1331A3 for ; Mon, 11 Sep 2017 12:35:49 -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=0NmjmP4gF1Qe7+eg+bzjUnxDOS5rOJrMkfNeSEAvg/w=; b=TwI/8nnNVDE49YDSQiDpS8bfpFS2q0YID0xCbLcwc78e0jX/JRbCss31V7l9euSYrziY9PzCBaGem7y7B13Vx7KE1JcBPrS0wBxfmIcrnk3y0YNgDwgw204gggQpC4tZDjAWix6ti74gjzV+UalQ9QT0abTXX0xkY+oBtLT7VP4= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0694.namprd21.prod.outlook.com (10.175.121.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.4; Mon, 11 Sep 2017 19:35:46 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0077.004; Mon, 11 Sep 2017 19:35:46 +0000 From: Mike Jones To: Eric Rescorla , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 Thread-Index: AQHTJQPOGSEV1sPnL0a/osPnuKlQ5aKm2zkwgAMD8+CABj6CQA== Date: Mon, 11 Sep 2017 19:35:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-09-05T16:11:52.0851161-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:6::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0694; 6:xZ0tkqtM3MIJKoLPAF2KyTxxlwd2PXpP4DR67n/zt7VeMgh75pJW1uYRBFJrjY9nHVjSzlwGIev9sTll+BzNzFTcBHjBrm/auNIbGk5lu5MzLdL5oebi8AE/C03aWiYEJx7SblrawmLJHl2XToncg1mvRY7mzgRdEAxhe/PsFCjoMq41meh6n69Vm0tM4edbb2KxgBAJQmi7A6j8Vq94xvYU6YzDJBbJ3toW4UTTubVrrSW02L1HsuKcDSKPe6s4p8Fxu/RtXYLv7GtoZBbF1V2F2kI/NjlhoJnd2y5JzfPg1g7w5i2EcJTSmBe58YmNV8gw80GjuBE5qNN0CsGovw==; 5:rxhG/ti6469fBhuOnNwNkxAPUtG0A9eh6OVfMPWRYN+K898PDED2QiGtZBhLeFIwxUefMz/9pvUxCwpxqoJ3p/Wg3b9Xjj0S/utzP9dTXwsvhPvYn9yESGAXu9aMVyRVE6q1qUcEdmFyk5nB+LFkjw==; 24:hrO76nRcpwwWG2ZUwUNmJzNxg92fSzeutUgJmHxvdxp/bNj+rc4SuLeMuvHRrL4b2Qg3mlYgzEXzV7vivkjDm6yc1xrXJeGweSeK6LH0cik=; 7:LpAk1J6dfsgiPPGdQYaNX3O5/kuAEiXc8Hpq6iXXmpqJ3upaLfc2MNnGoZwZNHJAoDoZ3496FDIj95KOvydhjqMPX/hugUWkco0Xg7YkyM5CWZ9pBQ8pXQ4Fjdbyt7wU9Il0C/mk67fkPjiZMlcp/ViIo4o63iR6s6Axllsv8qGyCjMo2BgNWvZYBeTFKdUd8WuY8y4KqCgCAnJd0se4QBGoHSOeV6bo4WbC0ZC0Z6g= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 57964811-5670-4f64-d326-08d4f94c4cea x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0694; x-ms-traffictypediagnostic: CY4PR21MB0694: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0694; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0694; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(199003)(51914003)(13464003)(189002)(377454003)(8676002)(97736004)(68736007)(81156014)(2900100001)(25786009)(10290500003)(966005)(8936002)(72206003)(53546010)(99286003)(55016002)(86612001)(229853002)(22452003)(53936002)(81166006)(86362001)(14454004)(2950100002)(6306002)(9686003)(77096006)(2906002)(5660300001)(105586002)(106356001)(305945005)(74316002)(3660700001)(7696004)(6506006)(76176999)(189998001)(2501003)(102836003)(6116002)(54356999)(7736002)(3280700002)(230783001)(8990500004)(6246003)(10090500001)(6436002)(101416001)(33656002)(50986999)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0694; H:CY4PR21MB0504.namprd21.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: 11 Sep 2017 19:35:46.8277 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0694 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 19:35:58 -0000 RXJpYywgSSBiZWxpZXZlIHRoYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtZGlzY292ZXJ5LTA3IGFkZHJlc3NlcyBhbGwgeW91ciBjb21tZW50cy4gIFRoYW5r cyBmb3IgdGhlbSBhZ2Fpbi4NCg0KSWYgeW91IGFncmVlLCBjYW4geW91IHBsZWFzZSBwcm9ncmVz cyB0aGUgZG9jdW1lbnQgdG8gdGhlIG5leHQgc3RlcD8NCg0KCQkJCVRoYW5rcywNCgkJCQktLSBN aWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQpTZW50OiBUaHVy c2RheSwgU2VwdGVtYmVyIDcsIDIwMTcgMjoyNSBQTQ0KVG86IEVyaWMgUmVzY29ybGEgPGVrckBy dGZtLmNvbT47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBRCBSZXZp ZXc6IGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA2DQoNCkRyYWZ0IC0wNyBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDcgY29udGFpbnMg dGhlc2UgcHJvcG9zZWQgcmVzb2x1dGlvbnMuICBUaGUgb25seSBjaGFuZ2UgaXMgdGhhdCBpbiBw bGFjZXMgd2hlcmUgSSdkIHByZXZpb3VzbHkgcHJvcG9zZWQgdG8gc2F5ICJJZiBvbWl0dGVkLCB0 aGVzZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGNhbm5vdCBiZSB1c2VkIiBJIG5vdyBzYXkgIlRo aXMgbWV0YWRhdGEgZW50cnkgTVVTVCBiZSBwcmVzZW50IGlmIGVpdGhlciBvZiB0aGVzZSBhdXRo ZW50aWNhdGlvbiBtZXRob2RzIGFyZSBzcGVjaWZpZWQgaW4gdGhlICJ7dG9rZW4scmV2b2NhdGlv bixpbnRyb3NwZWN0aW9ufV9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIiBlbnRyeS4g IE5vIGRlZmF1bHQgYWxnb3JpdGhtcyBhcmUgaW1wbGllZCBpZiB0aGlzIGVudHJ5IGlzIG9taXR0 ZWQuIg0KDQpJIG1hZGUgdGhlIGNoYW5nZSBiZWNhdXNlIHNheWluZyB0aGF0IHRoZXkgY2Fubm90 IGJlIHVzZWQgaXNuJ3QgYWN0dWFsbHkgY29ycmVjdC4gIFRoaXMgaW5mb3JtYXRpb24gY291bGQg YWx3YXlzIGhhdmUgYmVlbiBjb21tdW5pY2F0ZWQgb3V0LW9mLWJhbmQgdG8gdGhlIG1ldGFkYXRh Lg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWlr ZSBKb25lcyANClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciA1LCAyMDE3IDQ6MTIgUE0NClRvOiAn RXJpYyBSZXNjb3JsYScgPGVrckBydGZtLmNvbT47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBS RTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA2DQoN ClRoYW5rcyBmb3IgeW91ciB1c2VmdWwgcmV2aWV3LCBFcmljLiAgUHJvcG9zZWQgcmVzb2x1dGlv bnMgdG8gYWxsIGNvbW1lbnRzIGFyZSBpbmxpbmUgcHJlZml4ZWQgYnkgIk1pa2U+Ii4NCg0KRnJv bTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJp YyBSZXNjb3JsYQ0KU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMywgMjAxNyAzOjI2IFBNDQpUbzog b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRm LW9hdXRoLWRpc2NvdmVyeS0wNg0KDQpIaSBmb2xrcywNCg0KTm90ZTogdGhlIG9yaWdpbmFsIG9m IHRoaXMgcmV2aWV3IGlzIG9uIFBoYWJyaWNhdG9yIGF0Og0KDQrCoCBodHRwczovL21venBoYWIt aWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9ENw0KDQpJZiB5b3Ugd2FudCB0byBzZWUgY29tbWVu dHMgaW4gY29udGV4dCwgeW91IGNhbiBnbyB0aGVyZS4gQWxzbywgeW91IGNhbiBjcmVhdGUgYW4g YWNjb3VudCBhbmQgcmVzcG9uZCBpbmxpbmUgaWYgeW91IGxpa2UuDQpJZiB5b3UgZWxlY3QgdG8s IGxldCBtZSBrbm93IGlmIHlvdSBydW4gaW50byBwcm9ibGVtcy4NCg0KLUVrcg0KDQoNCkkgaGF2 ZSBtYXJrZWQgYSBudW1iZXIgb2YgcGxhY2VzIHdoZXJlIGl0IHNlZW1zIGxpa2UgeW91IGVpdGhl ciBuZWVkIGRlZmF1bHRzIG9yIG5lZWQgdG8gaW5kaWNhdGUgd2hhdCB0aGUgc2VtYW50aWNzIGFy ZSBpZiBtaXNzaW5nDQoNCg0KwqAgwqBUaGlzIG1ldGFkYXRhIGNhbiBlaXRoZXIgYmUgY29tbXVu aWNhdGVkIGluIGEgc2VsZi1hc3NlcnRlZCBmYXNoaW9uDQrCoCDCoG9yIGFzIGEgc2V0IG9mIHNp Z25lZCBtZXRhZGF0YSB2YWx1ZXMgcmVwcmVzZW50ZWQgYXMgY2xhaW1zIGluIGEgSlNPTiBJIGFz c3VtZSAic2VsZi1hc3NlcnRlZCIgaW4gdGhpcyBjYXNlIG1lYW5zICJhc3NlcnRlZCBieSB0aGUg c2VydmVyIG9yaWdpbiB2aWEgSFRUUFMiDQoNCk1pa2U+IFRoYW5rcyAtIEkgd2lsbCB1c2UgdGhp cyBsYW5ndWFnZS4NCg0KTGluZSAyMjINCsKgIMKgIMKgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMu wqAgU2VydmVycyBTSE9VTEQgc3VwcG9ydCAiUlMyNTYiLsKgIFRoZQ0KwqAgwqAgwqAgdmFsdWUg Im5vbmUiIE1VU1QgTk9UIGJlIHVzZWQuDQpXaGF0J3MgdGhlIGRlZmF1bHQgaWYgb21pdHRlZD8N Cg0KTWlrZT4gSSB3aWxsIGFkZCAiSWYgb21pdHRlZCwgdGhlc2UgYXV0aGVudGljYXRpb24gbWV0 aG9kcyBjYW5ub3QgYmUgdXNlZC4iDQoNCkxpbmUgMjM1DQrCoCDCoCDCoCByZXByZXNlbnRlZCBh cyBhIEpTT04gYXJyYXkgb2YgQkNQNDcgW1JGQzU2NDZdIGxhbmd1YWdlIHRhZw0KwqAgwqAgwqAg dmFsdWVzLg0KV2hhdCdzIHRoZSBkZWZhdWx0IGlmIG9taXR0ZWQ/DQoNCk1pa2U+IFRoZXJlIGlz IG5vIGRlZmF1bHQuICBJIHdpbGwgYWRkICJJZiBvbWl0dGVkLCB0aGUgc2V0IG9mIHN1cHBvcnRl ZCBsYW5ndWFnZXMgYW5kIHNjcmlwdHMgaXMgdW5zcGVjaWZpZWQuIg0KDQpMaW5lIDI2Nw0KwqAg wqAgwqAgIk9BdXRoIFRva2VuIEVuZHBvaW50IEF1dGhlbnRpY2F0aW9uIE1ldGhvZHMiIHJlZ2lz dHJ5DQrCoCDCoCDCoCBbSUFOQS5PQXV0aC5QYXJhbWV0ZXJzXS4NCldoYXQncyB0aGUgZGVmYXVs dCBpZiBvbWl0dGVkPw0KDQpNaWtlPiBJIHdpbGwgYWRkIGNsaWVudF9zZWNyZXRfYmFzaWMgYXMg dGhlIGRlZmF1bHQgLSBqdXN0IGxpa2UgaXQgYWxyZWFkeSB3YXMgZm9yIHRva2VuX2VuZHBvaW50 X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQuDQoNCkxpbmUgMjc1DQrCoCDCoCDCoCAiY2xpZW50X3Nl Y3JldF9qd3QiIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuwqAgVGhlIHZhbHVlICJub25lIiBNVVNU DQrCoCDCoCDCoCBOT1QgYmUgdXNlZC4NCldoYXQncyB0aGUgZGVmYXVsdCBpZiBvbWl0dGVkPw0K DQpNaWtlPiBJIHdpbGwgYWRkICJJZiBvbWl0dGVkLCB0aGVzZSBhdXRoZW50aWNhdGlvbiBtZXRo b2RzIGNhbm5vdCBiZSB1c2VkLiINCg0KTGluZSAyODgNCsKgIMKgIMKgIEFjY2VzcyBUb2tlbiBU eXBlcyIgcmVnaXN0cnkgW0lBTkEuT0F1dGguUGFyYW1ldGVyc10uIMKgKFRoZXNlDQrCoCDCoCDC oCB2YWx1ZXMgYXJlIGFuZCB3aWxsIHJlbWFpbiBkaXN0aW5jdCwgZHVlIHRvIFNlY3Rpb24gNy4y LikgV2hhdCdzIHRoZSBkZWZhdWx0IGlmIG9taXR0ZWQ/DQoNCk1pa2U+IFRoZXJlIGlzIG5vIG9i dmlvdXMgZGVmYXVsdC4gIFRoZXJlZm9yZSwgSSB3aWxsIGFkZCAiSWYgb21pdHRlZCwgdGhlIHNl dCBvZiBzdXBwb3J0ZWQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBNVVNUIGJlIGRldGVybWluZWQg Ynkgb3RoZXIgbWVhbnMuIg0KDQpMaW5lIDI5Ng0KwqAgwqAgwqAgImNsaWVudF9zZWNyZXRfand0 IiBhdXRoZW50aWNhdGlvbiBtZXRob2RzLsKgIFRoZSB2YWx1ZSAibm9uZSIgTVVTVA0KwqAgwqAg wqAgTk9UIGJlIHVzZWQuDQpXaGF0J3MgdGhlIGRlZmF1bHQgaWYgb21pdHRlZD8NCg0KTWlrZT4g SSB3aWxsIGFkZCAiSWYgb21pdHRlZCwgdGhlc2UgYXV0aGVudGljYXRpb24gbWV0aG9kcyBjYW5u b3QgYmUgdXNlZC4iDQoNCkxpbmUgMzA0DQrCoCDCoCDCoCBjaGFsbGVuZ2UgbWV0aG9kIHZhbHVl cyBhcmUgdGhvc2UgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSAiUEtDRQ0KwqAgwqAgwqAgQ29kZSBD aGFsbGVuZ2UgTWV0aG9kcyIgcmVnaXN0cnkgW0lBTkEuT0F1dGguUGFyYW1ldGVyc10uDQpXaGF0 J3MgdGhlIGRlZmF1bHQgaWYgb21pdHRlZD8NCg0KTWlrZT4gSSB3aWxsIGFkZCAiSWYgb21pdHRl ZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgUEtDRS4iDQoNCkxp bmUgMzQzDQrCoCDCoE1VU1QgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSAiV2VsbC1Lbm93biBV UklzIiByZWdpc3RyeQ0KwqAgwqBbSUFOQS53ZWxsLWtub3duXS4NCklNUE9SVEFOVDogU2hvdWxk bid0IHRoaXMgYmUgcmVxdWlyZWQgdG8gYmUgSFRUUFMNCg0KTWlrZT4gSSB3aWxsIGFkZCAiVGhp cyBwYXRoIE1VU1QgdXNlIHRoZSAiaHR0cHMiIHNjaGVtZS4iDQoNCkxpbmUgNTAwDQrCoCDCoGNs aWVudCBNVVNUIHBlcmZvcm0gYSBUTFMvU1NMIHNlcnZlciBjZXJ0aWZpY2F0ZSBjaGVjaywgcGVy IFJGQyA2MTI1DQrCoCDCoFtSRkM2MTI1XS7CoCBJbXBsZW1lbnRhdGlvbiBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBjYW4gYmUgZm91bmQgaW4NCsKgIMKgUmVjb21tZW5kYXRpb25zIGZvciBTZWN1 cmUgVXNlIG9mIFRMUyBhbmQgRFRMUyBbQkNQMTk1XS4NCkhtbS4uLi4gSSdtIHVuc3VyZSBhYm91 dCB3aGV0aGVyIHRoaXMgc2hvdWxkIGJlIGEgY2l0YXRpb24gdG8gMjgxOC4gSXMgdGhlIGdlbmVy YWwgZmVlbGluZyB0aGF0IDYxMjUgc3VwZXJjZWRlZCAyODE4Pw0KDQpNaWtlPiBPQXV0aCAyLjAg W1JGQyA2NzQ5XSBhbHNvIHJlcXVpcmVzIGFuIFJGQyA2MTI1IGNlcnRpZmljYXRlIHZhbGlkYXRp b24sIHNvIHRoaXMgaXMgaW4gbGluZSB3aXRoIG90aGVyIHVzZXMgb2YgdGhlIE9BdXRoIHByb3Rv Y29sIGZhbWlseS4NCg0KTGluZSA1NjQNCsKgIMKgVGhlIGZvbGxvd2luZyByZWdpc3RyYXRpb24g cHJvY2VkdXJlIGlzIHVzZWQgZm9yIHRoZSByZWdpc3RyeQ0KwqAgwqBlc3RhYmxpc2hlZCBieSB0 aGlzIHNwZWNpZmljYXRpb24uDQpUaGlzIHNlY3Rpb24gc2VlbXMgbGlrZSBpdCBuZWVkcyBSRkMy MTE5IGxhbmd1YWdlDQoNCk1pa2U+IFRoaXMgcmVnaXN0cnkgbGFuZ3VhZ2UgY2xvc2VseSBmb2xs b3dzIHRoYXQgaW4gT0F1dGggMi4wIFtSRkMgNjc0OV0gYW5kIHN1YnNlcXVlbnQgT0F1dGggc3Bl Y2lmaWNhdGlvbnMuICBJJ2QgcmF0aGVyIGtlZXAgdGhlbSBwYXJhbGxlbCB1bmxlc3Mgc29tZXRo aW5nIGlzbid0IGNsZWFyLg0KDQpMaW5lIDU2OA0KwqAgwqBWYWx1ZXMgYXJlIHJlZ2lzdGVyZWQg b24gYSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIFtSRkM1MjI2XSBiYXNpcw0KwqAgwqBhZnRlciBh IHR3by13ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlIG1haWx0bzpvYXV0aC1leHQtcmV2aWV3QGll dGYub3JnDQrCoCDCoG1haWxpbmcgbGlzdCwgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBE ZXNpZ25hdGVkIEV4cGVydHMuDQpXaGF0IGhhcHBlbnMgaWYgeW91IGRvbid0IGRvIGFueXRoaW5n IHdpdGhpbiB0d28gd2Vla3MuDQoNCkFzIGl0IHNheXMgbGF0ZXIgaW4gdGhpcyBzZWN0aW9uICJS ZWdpc3RyYXRpb24gcmVxdWVzdHMgdGhhdCBhcmUgdW5kZXRlcm1pbmVkIGZvciBhIHBlcmlvZCBs b25nZXIgdGhhbiAyMSBkYXlzIGNhbiBiZSBicm91Z2h0IHRvIHRoZSBJRVNHJ3MgYXR0ZW50aW9u ICh1c2luZyB0aGUgaWVzZ0BpZXRmLm9yZyBtYWlsaW5nIGxpc3QpIGZvciByZXNvbHV0aW9uLiIg IA0KDQpMaW5lIDc1Ng0KwqAgwqBvIMKgQ2hhbmdlIENvbnRyb2xsZXI6IElFU0cNCsKgIMKgbyDC oFNwZWNpZmljYXRpb24gRG9jdW1lbnQocyk6IFNlY3Rpb24gMiBvZiBbWyB0aGlzIHNwZWNpZmlj YXRpb24gXV0gRXh0cmEgd2hpdGVzcGFjZS4NCg0KQXJlIHlvdSB0YWxraW5nIGFib3V0IHRoZXJl IGJlaW5nIHR3byBzcGFjZXMgYmV0d2VlbiB0aGUgYnVsbGV0IGNoYXJhY3RlciAibyIgYW5kIHRo ZSBpdGVtcyBzdWNoIGFzICJDaGFuZ2UgQ29udHJvbGxlcjogSUVTRyI/ICBUaGF0J3Mgd2hhdCA8 bGlzdCBzdHlsZT0nc3ltYm9scyc+IGRvZXMuICBPciBhcmUgeW91IHdhbnRpbmcgbW9yZSB3aGl0 ZXNwYWNlIHNvbWV3aGVyZT8gIFBsZWFzZSBnaXZlIG1vcmUgY29udGV4dCBiZWNhdXNlIEknbSBu b3QgbG9va2luZyBhdCB0aGlzIG9uIFBoYWJyaWNhdG9yLiAgKEkgY3JlYXRlZCBhbiBhY2NvdW50 ICJtYmoiIGJ1dCBpdCB3YW50ZWQgbWUgdG8gaW5zdGFsbCBhIHNlY29uZCBmYWN0b3IgcGhvbmUg YXBwLCB3aGljaCBzZWVtZWQgbGlrZSBhIGJpdCBtdWNoLi4uKQ0KDQoJCQkJVGhhbmtzLA0KCQkJ CS0tIE1pa2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From nobody Tue Sep 19 06:27:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042E4134312 for ; Tue, 19 Sep 2017 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98_UAIUrVCCH for ; Tue, 19 Sep 2017 06:27:03 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE51132811 for ; Tue, 19 Sep 2017 06:27:03 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id e189so9982405ioa.4 for ; Tue, 19 Sep 2017 06:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WpcnpWWBWx3R3dQSq3hnHal5RwY2p58IrAUeHXaeAK8=; b=nqGa2C61748Wo8CNqLVcdHKxrZkF/EcZGKoSpbcMtlJI1hQfyG2ZgxWKSze0njpIDM 8KyhEkd0PeD5Cy07MK74W8IHxhjVlYFZP6mkhwWdT3fCw76gFBrV5sTnQsiA3BPE/of5 7Upvi0w2/NBkI3HSV7Sys4xDps8KPz9DfdhtX030p57RGfovQCkLwtUI/6z+i4FaPQZO gW06ofnMhoz/CnHyh+NO+vdwIXBnPdCI0a8qJ61wayDIkyhhCIYcfpCUe4FGMyXKzdHX FZPj50VNiytqNPkPoaJTnvAVuLMNdoetUlW0plv6ieSstHDwF0ScgZKorzDMflyWTPWP 4KmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WpcnpWWBWx3R3dQSq3hnHal5RwY2p58IrAUeHXaeAK8=; b=MMpjDDuImrkrOBC3p9QQA2S7f2wjIl7vQncOYQ0ZfZFSuWQwSDvDVq4i6ulE2VtGsw ucLkT8ASIWjfBt/zvqtnrtg3qVIuhoIbw2BsSqKgC4ghXtouRO4BlmQe3IiDXv252yye 1IVc3hX38C8N5tWUQYL5w/Wiy8xDEyYigSB+dHNTLTnFSHCHYCEmUHUk9CLNIeTZDAcp UEkFHy+j923OzG4uHFNKY28H/zSfJ8R/BM5LRr3JD0H+ZLzkm8XvstPdWPu3+TXJZNj0 GMxnVge+gGJGCcRa0PEErVa5+WTa22Kw8zgubhtFRkZN/2h6SgPB589N3Vfo8fY+vj3w Nz+g== X-Gm-Message-State: AHPjjUgUN0/oIfRYsnCpBqyC8xLQ4YnEL9Bq/TbJmOTimUn/aYv3Kz4o iiYEaum40NAHcwYGUN0fFnGt4M5e2g+3MWOauaBKTw== X-Google-Smtp-Source: AOwi7QDlRtS1BdMMf+rCM54UAunJ0M5Bt+7Arl0QvBgCzxO2Mw8tNM2lxscDT8AA1VroB1x8+5eAZkkF2QxPYn79wFM= X-Received: by 10.202.198.79 with SMTP id w76mr1469714oif.74.1505827622549; Tue, 19 Sep 2017 06:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.212 with HTTP; Tue, 19 Sep 2017 06:27:02 -0700 (PDT) From: =?UTF-8?Q?Stefan_B=C3=BCringer?= Date: Tue, 19 Sep 2017 15:27:02 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="001a11c14fa688febf05598ad0ba" Archived-At: Subject: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 13:27:05 -0000 --001a11c14fa688febf05598ad0ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, there were some discussions in January regarding recommendations for browser-based apps ( https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). I'd just like to ask if the Authorization Code Flow with PKCE is a valid option for Single-Page-Applications (in our case Angular), because Implicit Flow cannot be used in our scenario. Authorization Code Flow with PKCE eliminates the necessity for client secrets, but our concern is that exposing the refresh token to the SPA might be a security risk, compared to the Implicit Flow were no refresh token is exposed. What's your take on this? Kind regards, Stefan B=C3=BCringer P.S. I couldn't find that much on the internet regarding Authorization Code Flow with PKCE in SPAs, if you have some recommendations for good blog posts I would be grateful. --001a11c14fa688febf05598ad0ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

there were some discussions in Janu= ary regarding recommendations for browser-based apps (https://www.ietf.o= rg/mail-archive/web/oauth/current/msg16874.html).

<= div>I'd just like to ask if the Authorization Code Flow with PKCE is a = valid option for Single-Page-Applications (in our case Angular), because Im= plicit Flow cannot be used in our scenario.

Author= ization Code Flow with PKCE eliminates the necessity for client secrets, bu= t our concern is that exposing the refresh token to the SPA might be a secu= rity risk, compared to the Implicit Flow were no refresh token is exposed.<= /div>

What's your take on this?

=
Kind regards,
Stefan B=C3=BCringer

= P.S. I couldn't find that much on the internet regarding Authorization = Code Flow with PKCE in SPAs, if you have some recommendations for good blog= posts I would be grateful.
--001a11c14fa688febf05598ad0ba-- From nobody Tue Sep 19 14:33:58 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D6F1343AC for ; Tue, 19 Sep 2017 14:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMoBoYXd0xdt for ; Tue, 19 Sep 2017 14:33:54 -0700 (PDT) Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) (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 495FD134390 for ; Tue, 19 Sep 2017 14:33:54 -0700 (PDT) Received: by mail-vk0-f47.google.com with SMTP id p204so501489vkp.7 for ; Tue, 19 Sep 2017 14:33:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZPn6JjSBh6erjdaHE/dx61RXDfsapCZ+cjE0WYUh73k=; b=UrFEkFRI/LDGyRcugNDixGiTPIKQvAVgD81kyY7KS2zJ1D0HchnP0EThCEO2rijwMW ucIoNdOMgi8/aaMMnq8b+BDoKp5UcBcFrW6FiI4kxOGABebM5CSP7jqgsXrsQWKmZs7+ dVCWnhxxT1IN++sp1r6+tipjCKLFFW4UBU/0c2kCKqOU7mRAeCpDQWNy0Vbv6wNCi9Hq /v0GG7KW6LhGciwMk+00gf5KykrjwkMSbkLEJaprLag5KgnhdVyWVXe20/4mHBi2HXXg A9r6JTGV0bS9CtJd/jO9JH6bxONANtWOaMsWt/2JgQYGScGbrockCBfoeFjMKc9gigR2 noqg== X-Gm-Message-State: AHPjjUieo6LVU2eqchb/2Du+7va0er0V39QWYfsy9jUp4dTTpcDoH1XZ j1MPGKL8Q7rZeBJCbAiScaGdlLStUFzmGKm1Y2R/Rg== X-Google-Smtp-Source: AOwi7QA8fm5xucAvgVy3HxvYeYH1hyB/26z9JTDqpl2tzYCwDedeiTCGlu/mIDZv0EIf+7kVMUuBfkGLTXJEaNbq6tw= X-Received: by 10.31.192.70 with SMTP id q67mr2201949vkf.28.1505856832986; Tue, 19 Sep 2017 14:33:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.55.79 with HTTP; Tue, 19 Sep 2017 14:33:52 -0700 (PDT) In-Reply-To: References: From: Bill Burke Date: Tue, 19 Sep 2017 17:33:52 -0400 Message-ID: To: =?UTF-8?Q?Stefan_B=C3=BCringer?= Cc: OAuth WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 21:33:56 -0000 I'd be curious to the response to this too. Seems to me that refresh token has the same possible security risks in an Angular app as an access token, except the refresh token is valid longer....Still, if you did the implicit flow, you'd have to have longer access token timeouts as it would be really annoying for the user to have to login again and again in a long session with your Angular app. We have a javascript adapter that does Authz Code Flow with PKCE for our Angular app. It also does CORS checks on the code to token XHR request just in case on the IDP side. On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer wrote: > Hi, > > there were some discussions in January regarding recommendations for > browser-based apps > (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). > > I'd just like to ask if the Authorization Code Flow with PKCE is a valid > option for Single-Page-Applications (in our case Angular), because Implic= it > Flow cannot be used in our scenario. > > Authorization Code Flow with PKCE eliminates the necessity for client > secrets, but our concern is that exposing the refresh token to the SPA mi= ght > be a security risk, compared to the Implicit Flow were no refresh token i= s > exposed. > > What's your take on this? > > Kind regards, > Stefan B=C3=BCringer > > P.S. I couldn't find that much on the internet regarding Authorization Co= de > Flow with PKCE in SPAs, if you have some recommendations for good blog po= sts > I would be grateful. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Bill Burke Red Hat From nobody Tue Sep 19 14:47:42 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2618A134343 for ; Tue, 19 Sep 2017 14:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12Xea3kGAFRz for ; Tue, 19 Sep 2017 14:47:39 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008751343AC for ; Tue, 19 Sep 2017 14:47:38 -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 v8JLlZMv009701 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Sep 2017 21:47:35 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8JLlYfo015882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Sep 2017 21:47:35 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8JLlYGE031043; Tue, 19 Sep 2017 21:47:34 GMT Received: from [25.163.118.13] (/72.143.234.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Sep 2017 14:47:34 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Tue, 19 Sep 2017 14:47:31 -0700 Cc: =?utf-8?Q?Stefan_B=C3=BCringer?= , OAuth WG Content-Transfer-Encoding: quoted-printable Message-Id: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> References: To: Bill Burke X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 21:47:41 -0000 Except a refresh token is not purely bearer. The client is required to authe= nticate to use it.=20 Phil > On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >=20 > I'd be curious to the response to this too. >=20 > Seems to me that refresh token has the same possible security risks in > an Angular app as an access token, except the refresh token is valid > longer....Still, if you did the implicit flow, you'd have to have > longer access token timeouts as it would be really annoying for the > user to have to login again and again in a long session with your > Angular app. >=20 > We have a javascript adapter that does Authz Code Flow with PKCE for > our Angular app. It also does CORS checks on the code to token XHR > request just in case on the IDP side. >=20 >> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer wrote: >> Hi, >>=20 >> there were some discussions in January regarding recommendations for >> browser-based apps >> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). >>=20 >> I'd just like to ask if the Authorization Code Flow with PKCE is a valid >> option for Single-Page-Applications (in our case Angular), because Implic= it >> Flow cannot be used in our scenario. >>=20 >> Authorization Code Flow with PKCE eliminates the necessity for client >> secrets, but our concern is that exposing the refresh token to the SPA mi= ght >> be a security risk, compared to the Implicit Flow were no refresh token i= s >> exposed. >>=20 >> What's your take on this? >>=20 >> Kind regards, >> Stefan B=C3=BCringer >>=20 >> P.S. I couldn't find that much on the internet regarding Authorization Co= de >> Flow with PKCE in SPAs, if you have some recommendations for good blog po= sts >> I would be grateful. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 > Bill Burke > Red Hat >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Sep 19 14:54:55 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A24132D42 for ; Tue, 19 Sep 2017 14:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, URIBL_BLOCKED=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 Lj3SRwPXsCC4 for ; Tue, 19 Sep 2017 14:54:51 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 70B04132397 for ; Tue, 19 Sep 2017 14:54:51 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id i195so554540pgd.9 for ; Tue, 19 Sep 2017 14:54:51 -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=yjai3S0GJSBKIwpf2b/XeHeowGiTZCvuXUF3krc3Ir0=; b=AHTzqzmOgnb8VaArr8H9hzmlnrcEf13HJTQeP5JX0u+qCMszk7qB7j9X2TFgatRzZa ox3pVXfBX1KdVoSbAJ3NhWI0CjU7fIc/wiDqonGsV4TgFyEGwQK0c8+6mlmhkNGIzgcN 9DvRFv5ZRd9YNoqG7dfFQOSrnJWGccMOW1W2o5FklFZ99Koe3h1VBWlLWQExrcCphD8J /aLjbh8y3Kl3RSCa9UEihdtW7T3UbMipscEbCWJtpCbyXC0SHtZi5pbbLgcDy4qEHfXi ZpsxgK1XvJ6Ih6b+g3QoABgA56RI1ATAobwf/vMRI1/OW/nc+v/R2o6/iV9/wyxfawzi JoCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yjai3S0GJSBKIwpf2b/XeHeowGiTZCvuXUF3krc3Ir0=; b=ngfYdlChXf/te3FUEkuD2u1kAPehaa5ZclbC+rj2AwApHswWVb1cFKV8m3ZNzlEuPq mqrtMup7PBzEPnXZIsRQ8v0ozWPnauwchD4RAwImBwhYH/GJ6CgpiBxK7NOdmeNkPLDn 4H4tGk8znTC/ojrp1Y2+TIpru2TFAGrANPkAd7jugpQmbti3pY1tW4BH8CGYKx7/n2vv tGqQGQYiWXSKfFik4Dn4zeSQJtmDl2VMkLcnbCPIbbP/IGTO6ZIqDiPjUCINR+f+7Rg8 5suZBXIa32sTAhbEse2xPN/6FiOFPDwm7QLXrbgKt2l6AyU6fnZ8BWqI0fy1d2CxWxUp LILw== X-Gm-Message-State: AHPjjUjAqKXwNeMz5feCGCJf+4kEQ9ViAY4sLF7t/K+5nNuqdG5uiVbg jJAAn9AL27mV0X4vCYSVN1pbgw6I2IU= X-Google-Smtp-Source: AOwi7QCiejuVNzMzM45ZdI5kQXZ3MWIWZXyzR/OSjq8a9MUJiIGe8FgJNKv4H9gin2qN46hwKIp5Kw== X-Received: by 10.99.127.4 with SMTP id a4mr52958pgd.124.1505858090566; Tue, 19 Sep 2017 14:54:50 -0700 (PDT) Received: from [10.73.197.170] (mobile-166-170-39-127.mycingular.net. [166.170.39.127]) by smtp.gmail.com with ESMTPSA id g16sm5817593pfd.6.2017.09.19.14.54.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 14:54:49 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-585688D5-A18B-41D2-8F49-5EC8D6874AE7 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14G60) In-Reply-To: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> Date: Wed, 20 Sep 2017 05:54:45 +0800 Cc: Bill Burke , OAuth WG Content-Transfer-Encoding: 7bit Message-Id: <89A32B3A-849D-471C-9700-85815DC1C58D@manicode.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> To: "Phil Hunt (IDM)" Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 21:54:53 -0000 --Apple-Mail-585688D5-A18B-41D2-8F49-5EC8D6874AE7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One of the reasons I see so many security folk discouraging implicit in web a= pplications (like your Angular scenario) is because even though refresh toke= ns and similar require authentication, how do you store that info securely i= n a browser? One XSS and it's http://m.youtube.com/watch?v=3Ddsx2vdn7gpY - Jim > On Sep 20, 2017, at 5:47 AM, Phil Hunt (IDM) wrote:= >=20 > Except a refresh token is not purely bearer. The client is required to aut= henticate to use it.=20 >=20 > Phil >=20 >> On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >>=20 >> I'd be curious to the response to this too. >>=20 >> Seems to me that refresh token has the same possible security risks in >> an Angular app as an access token, except the refresh token is valid >> longer....Still, if you did the implicit flow, you'd have to have >> longer access token timeouts as it would be really annoying for the >> user to have to login again and again in a long session with your >> Angular app. >>=20 >> We have a javascript adapter that does Authz Code Flow with PKCE for >> our Angular app. It also does CORS checks on the code to token XHR >> request just in case on the IDP side. >>=20 >>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer wrote: >>> Hi, >>>=20 >>> there were some discussions in January regarding recommendations for >>> browser-based apps >>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). >>>=20 >>> I'd just like to ask if the Authorization Code Flow with PKCE is a valid= >>> option for Single-Page-Applications (in our case Angular), because Impli= cit >>> Flow cannot be used in our scenario. >>>=20 >>> Authorization Code Flow with PKCE eliminates the necessity for client >>> secrets, but our concern is that exposing the refresh token to the SPA m= ight >>> be a security risk, compared to the Implicit Flow were no refresh token i= s >>> exposed. >>>=20 >>> What's your take on this? >>>=20 >>> Kind regards, >>> Stefan B=C3=BCringer >>>=20 >>> P.S. I couldn't find that much on the internet regarding Authorization C= ode >>> Flow with PKCE in SPAs, if you have some recommendations for good blog p= osts >>> I would be grateful. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Bill Burke >> Red Hat >>=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-585688D5-A18B-41D2-8F49-5EC8D6874AE7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
One of the reasons I see so many secur= ity folk discouraging implicit in web applications (like your Angular scenar= io) is because even though refresh tokens and similar require authentication= , how do you store that info securely in a browser? One XSS and it's http://m.youtube.com/wa= tch?v=3Ddsx2vdn7gpY

- Jim
=
On Sep 20, 2017, at 5:47 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

Except a refresh token is not purely bearer. The c= lient is required to authenticate to use it.

Phil

On Sep 19= , 2017, at 2:33 PM, Bill Burke <bbur= ke@redhat.com> wrote:

I'd be curio= us to the response to this too.

Seems to m= e that refresh token has the same possible security risks in
an Angular app as an access token, e= xcept the refresh token is valid
longer....Still, if you did the implicit flow, you'd have to hav= e
longer access token= timeouts as it would be really annoying for the
user to have to login again and again in a long s= ession with your
Angu= lar app.

<= /blockquote>
We have a javascript adapter tha= t does Authz Code Flow with PKCE for
our Angular app.  It also does CORS checks on the code t= o token XHR
request j= ust in case on the IDP side.

On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer <sbueringer@gmail.com> wrote:
Hi,

there were some discus= sions in January regarding recommendations for
browser-bas= ed apps
(https://www.ietf.org/mail-archive/web/oauth/cur= rent/msg16874.html).

I'd just like t= o ask if the Authorization Code Flow with PKCE is a valid
= option for Single-Page-Applications (in our case Angular), because Implicit<= /span>
Flow cannot be used in our scenario.

Authorization Code Flow with PKCE eliminates the necessity f= or client
secrets, but our concern is that exposing the re= fresh token to the SPA might
be a security risk, compared t= o the Implicit Flow were no refresh token is
exposed.

=
What's your take on this?
=
Kind regards,
Stefan B=C3=BCringer

=
P.S. I couldn't find that much on the intern= et regarding Authorization Code
Flow with PKCE in SPAs, if= you have some recommendations for good blog posts
I would= be grateful.
=

_________________________= ______________________
OAuth mailing list
= OAuth@ietf.org
=
https://www.ietf.org/mail= man/listinfo/oauth

=


<= br>
--
<= blockquote type=3D"cite">Bill Burke
Red Hat

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

___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth
= --Apple-Mail-585688D5-A18B-41D2-8F49-5EC8D6874AE7-- From nobody Tue Sep 19 15:03:20 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC49134390 for ; Tue, 19 Sep 2017 15:03:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m8FBtnLCRsf for ; Tue, 19 Sep 2017 15:03:16 -0700 (PDT) Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B86134343 for ; Tue, 19 Sep 2017 15:03:16 -0700 (PDT) Received: from pps.filterd (m0074419.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8JM39dC017128 for ; Tue, 19 Sep 2017 17:03:13 -0500 Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by mx0b-0019e102.pphosted.com with ESMTP id 2d37fqrnqy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 19 Sep 2017 17:03:13 -0500 Received: by mail-oi0-f69.google.com with SMTP id f3so39103oia.4 for ; Tue, 19 Sep 2017 15:03:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nN5UIwRbKJQWSiLYBWMRkxd+rOQ6EiM+NvMUa3wNeIc=; b=L4jGF3bwVImYE6crWD6qOj2pkgKVM+D/ZO8Ee4TG3nfX00DSNi3l9qfetDfOleBwTK cEDa7KZWLmSKyTwV+Ga6Bb9hSl3Z2HO2ChNHQ2LpZY6uTWZ7wnnJkfMBfX0gDwHZ5K/z H0aCHWRCVfYpWrcjALQuWHkDJN9iHPOULd65ks53ZOmNVymoqEyVdgReT7T1u0IinbwU grrRwzxz2pH763psFbzgfxavp4yVuOXY21cCEOiIV5FLhp6Q3N5pXin8xdcNRgOkmG9o Vof567Y+wKO/9pu2lel5pmwJIsQETanLBnaER2KoussctXZ2CzFwVkCmsbjpfnQ537ID uX/g== X-Gm-Message-State: AHPjjUhyaPCQDkgYAXOnaSkS1a31h1f7XY3agHcMIzLdehju3R3IiSYm oxf5skeF87gx12HP4zedbxS0t4NiU745oHUeirMJ1jCDCViLpobo6ebKw5ZVhvFsitT5AQEcUdS zfjkYVPsEK9qDAw92cv6ZUw== X-Received: by 10.202.71.151 with SMTP id u145mr3171984oia.222.1505858592697; Tue, 19 Sep 2017 15:03:12 -0700 (PDT) X-Google-Smtp-Source: AOwi7QALFAn0nipi93scpWDuuW/MWX/nNBes/VQwfqZN/lcQlQKnuN0G3yAMyXHRi9UlirHYTGMVTZH3RjemBfxUxds= X-Received: by 10.202.71.151 with SMTP id u145mr3171967oia.222.1505858592405; Tue, 19 Sep 2017 15:03:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.32.139 with HTTP; Tue, 19 Sep 2017 15:02:51 -0700 (PDT) In-Reply-To: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> From: Adam Lewis Date: Tue, 19 Sep 2017 17:02:51 -0500 Message-ID: To: "Phil Hunt (IDM)" Cc: Bill Burke , OAuth WG Content-Type: multipart/alternative; boundary="001a113e51127bc6ac055992062e" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709190301 Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 22:03:19 -0000 --001a113e51127bc6ac055992062e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Only for confidential clients. No authentication is required for public clients. On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) wrote: > Except a refresh token is not purely bearer. The client is required to > authenticate to use it. > > Phil > > > On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: > > > > I'd be curious to the response to this too. > > > > Seems to me that refresh token has the same possible security risks in > > an Angular app as an access token, except the refresh token is valid > > longer....Still, if you did the implicit flow, you'd have to have > > longer access token timeouts as it would be really annoying for the > > user to have to login again and again in a long session with your > > Angular app. > > > > We have a javascript adapter that does Authz Code Flow with PKCE for > > our Angular app. It also does CORS checks on the code to token XHR > > request just in case on the IDP side. > > > >> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer > wrote: > >> Hi, > >> > >> there were some discussions in January regarding recommendations for > >> browser-based apps > >> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). > >> > >> I'd just like to ask if the Authorization Code Flow with PKCE is a val= id > >> option for Single-Page-Applications (in our case Angular), because > Implicit > >> Flow cannot be used in our scenario. > >> > >> Authorization Code Flow with PKCE eliminates the necessity for client > >> secrets, but our concern is that exposing the refresh token to the SPA > might > >> be a security risk, compared to the Implicit Flow were no refresh toke= n > is > >> exposed. > >> > >> What's your take on this? > >> > >> Kind regards, > >> Stefan B=C3=BCringer > >> > >> P.S. I couldn't find that much on the internet regarding Authorization > Code > >> Flow with PKCE in SPAs, if you have some recommendations for good blog > posts > >> I would be grateful. > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > -- > > Bill Burke > > Red Hat > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113e51127bc6ac055992062e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Only for confidential clients.=C2=A0 No authentication is = required for public clients.

On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil= .hunt@oracle.com> wrote:
Ex= cept a refresh token is not purely bearer. The client is required to authen= ticate to use it.

Phil

> On Sep 19, 2017, at 2:33 PM, Bill Burke <bburke@redhat.com> wrote:
>
> I'd be curious to the response to this too.
>
> Seems to me that refresh token has the same possible security risks in=
> an Angular app as an access token, except the refresh token is valid > longer....Still, if you did the implicit flow, you'd have to have<= br> > longer access token timeouts as it would be really annoying for the > user to have to login again and again in a long session with your
> Angular app.
>
> We have a javascript adapter that does Authz Code Flow with PKCE for > our Angular app.=C2=A0 It also does CORS checks on the code to token X= HR
> request just in case on the IDP side.
>
>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer <sbueringer@gmail.com> wrote:
>> Hi,
>>
>> there were some discussions in January regarding recommendations f= or
>> browser-based apps
>> (https://www.ietf.org/mail= -archive/web/oauth/current/msg16874.html).
>>
>> I'd just like to ask if the Authorization Code Flow with PKCE = is a valid
>> option for Single-Page-Applications (in our case Angular), because= Implicit
>> Flow cannot be used in our scenario.
>>
>> Authorization Code Flow with PKCE eliminates the necessity for cli= ent
>> secrets, but our concern is that exposing the refresh token to the= SPA might
>> be a security risk, compared to the Implicit Flow were no refresh = token is
>> exposed.
>>
>> What's your take on this?
>>
>> Kind regards,
>> Stefan B=C3=BCringer
>>
>> P.S. I couldn't find that much on the internet regarding Autho= rization Code
>> Flow with PKCE in SPAs, if you have some recommendations for good = blog posts
>> I would be grateful.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=

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

--001a113e51127bc6ac055992062e-- From nobody Tue Sep 19 15:32:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0635134390 for ; Tue, 19 Sep 2017 15:32:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wyjQCicGtIvK for ; Tue, 19 Sep 2017 15:32:55 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 040D513301C for ; Tue, 19 Sep 2017 15:32:54 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id o3so125951qte.6 for ; Tue, 19 Sep 2017 15:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=A7Tcd6lsRP7OYc8CHdOkSIR/guXbmKcph8o6UUw3u7I=; b=jKAukIpsLq5bXTKJFQrPH6VLG1YG3jTFUFJLw+ZQBmjyIi6GnWwG0WusJ15LElqQc5 umnKtYX28aZF/a7kq2kRVbla+cByplgJyU8tQ60Ib2fFWWEfe/il7IsTHI0KX6asSqVA oEuzsvWvTZP2+dzlriNZpe/OQNHDihkq+dmQHH5fcq/you0uEBVu0NNnBDtjM5ZLpL7r nXYtThscPYtphM9FWMxygat752TZ/c2OLyi4VITJmubH8WmxSiqIJZVHdECDNwvteNPX FMzBY4b1vUldwbT9atIxOd7yZ/cm+fx4MFe7fWLYsWAc93UkN8xxsb/1hObdjF6BJ9vL seeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=A7Tcd6lsRP7OYc8CHdOkSIR/guXbmKcph8o6UUw3u7I=; b=gd6gdjJ1E8PyQYQKYUYXeRcd1pvloQjrqdCWHZ/SkOZojmrpv2773CVp0IdL9WSXgE cEv0kOrXERogaVHe7p4H0Z8gzNUfJAgObuYQNJMiEkwy/HnWKK245Du3AQT503KMjI6a 97QV7D/VRkgIZfsdqmoPYlHhJYrn1B/Zglmg8c8e+YXvFTpQhjAQRVfcckiAB+myzeg/ i+C36k064QiUGzWaoKPfUj9wjXNJzN9IOpN7o8xJAiIKV+uC4Qa6O2QXcccAk13X4JvJ 5ZJaUq16qND8M8nQwYM8w6EJ7GomOmm6wuVw5/SFhz2TedZoViMSIhRAftPl5gOlSLlU 6ANw== X-Gm-Message-State: AHPjjUhZ9pGt4p0zPp8I5+Hj5n2hS08Rl8XXHl/4U5IIrsNTnxUlc4XP XgGOvYMaTkhxLpFFODiUtQz7But7vPc= X-Google-Smtp-Source: AOwi7QBI6EMsjd/lmPORzChVvIc1Wr7JLQVyE93sMYmfVUkVHNB+7dEinsa1wYBVwil1c+1YmjmbHg== X-Received: by 10.237.34.118 with SMTP id o51mr4436935qtc.36.1505860373588; Tue, 19 Sep 2017 15:32:53 -0700 (PDT) Received: from [192.168.8.100] ([181.201.64.103]) by smtp.gmail.com with ESMTPSA id i124sm278570qkf.84.2017.09.19.15.32.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 15:32:52 -0700 (PDT) From: John Bradley Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 19 Sep 2017 19:32:42 -0300 References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> To: OAuth WG In-Reply-To: Message-Id: <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113a6848ae49a0055992708d" Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 22:32:58 -0000 --001a113a6848ae49a0055992708d Content-Type: multipart/alternative; boundary="Apple-Mail=_2C8EFB3B-2030-412F-B7E0-C474C5F8BA40" --Apple-Mail=_2C8EFB3B-2030-412F-B7E0-C474C5F8BA40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Right, Refresh token is bearer for native apps, that is why we came up = with PKCE to protect code. For Angular the code flow with PKCE is probably better than the token = response type. =20 However with bearer tokens it is still riskier than code with a = confidential client so the AS should take that into account and not = allow refresh tokens to live forever. One future way to protect refresh tokens and perhaps Access tokens is to = use token binding to bind the tokens to the user agent. You could do = that now for refresh tokens in Edge (Chrome has TB off by default = still). =20 I think more work needs to be done to come up with a best practice for = SPA. John B. > On Sep 19, 2017, at 7:02 PM, Adam Lewis = wrote: >=20 > Only for confidential clients. No authentication is required for = public clients. >=20 > On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) > wrote: > Except a refresh token is not purely bearer. The client is required to = authenticate to use it. >=20 > Phil >=20 > > On Sep 19, 2017, at 2:33 PM, Bill Burke > wrote: > > > > I'd be curious to the response to this too. > > > > Seems to me that refresh token has the same possible security risks = in > > an Angular app as an access token, except the refresh token is valid > > longer....Still, if you did the implicit flow, you'd have to have > > longer access token timeouts as it would be really annoying for the > > user to have to login again and again in a long session with your > > Angular app. > > > > We have a javascript adapter that does Authz Code Flow with PKCE for > > our Angular app. It also does CORS checks on the code to token XHR > > request just in case on the IDP side. > > > >> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer = > wrote: > >> Hi, > >> > >> there were some discussions in January regarding recommendations = for > >> browser-based apps > >> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html = ). > >> > >> I'd just like to ask if the Authorization Code Flow with PKCE is a = valid > >> option for Single-Page-Applications (in our case Angular), because = Implicit > >> Flow cannot be used in our scenario. > >> > >> Authorization Code Flow with PKCE eliminates the necessity for = client > >> secrets, but our concern is that exposing the refresh token to the = SPA might > >> be a security risk, compared to the Implicit Flow were no refresh = token is > >> exposed. > >> > >> What's your take on this? > >> > >> Kind regards, > >> Stefan B=C3=BCringer > >> > >> P.S. I couldn't find that much on the internet regarding = Authorization Code > >> Flow with PKCE in SPAs, if you have some recommendations for good = blog posts > >> I would be grateful. > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth = > >> > > > > > > > > -- > > Bill Burke > > Red Hat > > > > _______________________________________________ > > 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2C8EFB3B-2030-412F-B7E0-C474C5F8BA40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Right,  Refresh token is bearer for native apps, that is = why we came up with PKCE to protect code.

For Angular the code flow with PKCE is = probably better than the token response type.   

However with bearer = tokens it is still riskier than code with a confidential client so the = AS should take that into account and not allow refresh tokens to live = forever.

One = future way to protect refresh tokens and perhaps Access tokens is to use = token binding to bind the tokens to the user agent.   You could do = that now for refresh tokens in Edge (Chrome has TB off by default = still).  

I= think more work needs to be done to come up with a best practice for = SPA.

John = B.

On Sep 19, 2017, at 7:02 PM, Adam Lewis = <adam.lewis@motorolasolutions.com> wrote:

Only for confidential clients.  No authentication is = required for public clients.

On Tue, Sep 19, 2017 at 4:47 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Except a refresh token = is not purely bearer. The client is required to authenticate to use = it.

Phil

> On Sep 19, 2017, at 2:33 PM, Bill Burke <bburke@redhat.com> = wrote:
>
> I'd be curious to the response to this too.
>
> Seems to me that refresh token has the same possible security risks = in
> an Angular app as an access token, except the refresh token is = valid
> longer....Still, if you did the implicit flow, you'd have to = have
> longer access token timeouts as it would be really annoying for = the
> user to have to login again and again in a long session with = your
> Angular app.
>
> We have a javascript adapter that does Authz Code Flow with PKCE = for
> our Angular app.  It also does CORS checks on the code to = token XHR
> request just in case on the IDP side.
>
>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer <sbueringer@gmail.com> wrote:
>> Hi,
>>
>> there were some discussions in January regarding = recommendations for
>> browser-based apps
>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>>
>> I'd just like to ask if the Authorization Code Flow with PKCE = is a valid
>> option for Single-Page-Applications (in our case Angular), = because Implicit
>> Flow cannot be used in our scenario.
>>
>> Authorization Code Flow with PKCE eliminates the necessity for = client
>> secrets, but our concern is that exposing the refresh token to = the SPA might
>> be a security risk, compared to the Implicit Flow were no = refresh token is
>> exposed.
>>
>> What's your take on this?
>>
>> Kind regards,
>> Stefan B=C3=BCringer
>>
>> P.S. I couldn't find that much on the internet regarding = Authorization Code
>> Flow with PKCE in SPAs, if you have some recommendations for = good blog posts
>> I would be grateful.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

= --Apple-Mail=_2C8EFB3B-2030-412F-B7E0-C474C5F8BA40-- --001a113a6848ae49a0055992708d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEICE0ROVniq/Hz3fXuVcw5UDV6J7M hM0QQvDSAD1GiMpZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDkxOTIyMzI1NFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQC0SANhnNHUBNyNe3fTznx4bx/ZPfwqIC47s5c2o7DrJjwG pfOR6HwbawD7oFBXj0Ls+ikY8CEtJsG5vAOWMVJ7TG1JPE1N2lp35HNnSjMJx8GCXHZXqr/izsR+ c8L3hMuP/pXtgGt4/xCXtoHzRma7+LMBTpbR83vuWxeWIbquNbjq+1FwIt3U+pLhWeonsoV9vP/i 90z6FK0x8XrAmpkWII1l+NoAbojWLhIfbuI365kBc7kVKitdMENh1w/c5oKdZEKpbyCtGLPTnyRo 1WIrfkpnG8B8InVZE1/0J3aiugeaxYAVxsrXzTD6wnUShc+tILQ3xzT43ZsZdSuKibEf --001a113a6848ae49a0055992708d-- From nobody Tue Sep 19 16:49:07 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E7C133023 for ; Tue, 19 Sep 2017 16:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2jKfMCKCaKT for ; Tue, 19 Sep 2017 16:49:03 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1F6133011 for ; Tue, 19 Sep 2017 16:49:03 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id z84so630742pfi.2 for ; Tue, 19 Sep 2017 16:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y201OXP7YCsIE7Zewtb7FvzNNbTSXEGxuNk0d8MXqxo=; b=SAOL+FDoeIOYGgBR5vVsa0qUAPLVRFVVCdS+loxJLCWVTNBLbbx3taIPSiuzXxdHXI Zyas84NpY5ZSHPhRTYdfnRjEa6GRWhADazgN4CktJkNZzmJmCOEAbN2aVxWSCrjI0Nxe tYn0yD+o/CCORe0RNbUaD4gnpsuRFGz+OiMK/c/JVvgbyDJoYW1rMWOww5CH+07nDgiY FHwvZr+FV0dua0JOsONgDf/g3AzSCX9D3pOu57h5RORVNlZBk6uMrqJebt6y5gM2R339 d3hzNxEOY9Xyv9FNeeQ9jI6RSBfNr1b8+P9qSq5NXUa0xe41kYsnvjxmD+kYpNY71IS7 BdSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y201OXP7YCsIE7Zewtb7FvzNNbTSXEGxuNk0d8MXqxo=; b=NlxvF0pJIa3xIcCXkhkeHfV0H0AZBeWRoXUdXT4kMdDD/td+sfXpp9/b1l2xW0IKkj ZxbVb6mC61IsFcs/F/7IQxfeDGdvfbj+eQwjR5tO1SkcKcJLXbWRoGBaBk3QEyDti2tq IEAXmoxE2GpfaEolItLg/VjLFUA+j4R3yicW994JjmOgomQegKydsWrEknC1Fg3Z7jTO IXb/EWiyGU0yUcIxTOWS6xyEKyZ/vBNgVLipAMs7zCfOMeYpv2pwD5rGSJy/OH3K9iRT YjSXzw9igmN7M74rldgaMD6Nn3apYA9xi6iQMBvmcBJxN+pXhR3A6SFjkoBabL/qNrYN Rd2A== X-Gm-Message-State: AHPjjUieTtqZbftLtdiTQF3XHQydGmzDhZHxjgnj1rAkTsgA1c4xdmUp 4VK/ZPkXAKM73jk9C168IW7q841c X-Google-Smtp-Source: AOwi7QA0PQYmqZm4RgP8+UNymeaHfJcgRsRjhmLd9rdyShHNj15PTxIzxH23mJ5f14372MSfNpWvpA== X-Received: by 10.98.236.150 with SMTP id e22mr267638pfm.203.1505864942680; Tue, 19 Sep 2017 16:49:02 -0700 (PDT) Received: from [172.16.80.193] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id b68sm5091449pfk.23.2017.09.19.16.49.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 16:49:01 -0700 (PDT) From: nov matake Message-Id: <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_10979C48-C6D2-4677-B2DE-3183712D3C1C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 20 Sep 2017 08:48:59 +0900 In-Reply-To: <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> Cc: OAuth WG To: John Bradley References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 23:49:06 -0000 --Apple-Mail=_10979C48-C6D2-4677-B2DE-3183712D3C1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =10Why not using http-only cookies instead of refresh tokens? If the app can interact with AuthZ server through a hidden iframe with = prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. If your SAP is running on a different domain with the backend server, = Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden = iframe way though. > On Sep 20, 2017, at 7:32, John Bradley wrote: >=20 > Right, Refresh token is bearer for native apps, that is why we came = up with PKCE to protect code. >=20 > For Angular the code flow with PKCE is probably better than the token = response type. =20 >=20 > However with bearer tokens it is still riskier than code with a = confidential client so the AS should take that into account and not = allow refresh tokens to live forever. >=20 > One future way to protect refresh tokens and perhaps Access tokens is = to use token binding to bind the tokens to the user agent. You could = do that now for refresh tokens in Edge (Chrome has TB off by default = still). =20 >=20 > I think more work needs to be done to come up with a best practice for = SPA. >=20 > John B. >=20 >> On Sep 19, 2017, at 7:02 PM, Adam Lewis = > wrote: >>=20 >> Only for confidential clients. No authentication is required for = public clients. >>=20 >> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) = > wrote: >> Except a refresh token is not purely bearer. The client is required = to authenticate to use it. >>=20 >> Phil >>=20 >> > On Sep 19, 2017, at 2:33 PM, Bill Burke > wrote: >> > >> > I'd be curious to the response to this too. >> > >> > Seems to me that refresh token has the same possible security risks = in >> > an Angular app as an access token, except the refresh token is = valid >> > longer....Still, if you did the implicit flow, you'd have to have >> > longer access token timeouts as it would be really annoying for the >> > user to have to login again and again in a long session with your >> > Angular app. >> > >> > We have a javascript adapter that does Authz Code Flow with PKCE = for >> > our Angular app. It also does CORS checks on the code to token XHR >> > request just in case on the IDP side. >> > >> >> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer = > wrote: >> >> Hi, >> >> >> >> there were some discussions in January regarding recommendations = for >> >> browser-based apps >> >> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html = ). >> >> >> >> I'd just like to ask if the Authorization Code Flow with PKCE is a = valid >> >> option for Single-Page-Applications (in our case Angular), because = Implicit >> >> Flow cannot be used in our scenario. >> >> >> >> Authorization Code Flow with PKCE eliminates the necessity for = client >> >> secrets, but our concern is that exposing the refresh token to the = SPA might >> >> be a security risk, compared to the Implicit Flow were no refresh = token is >> >> exposed. >> >> >> >> What's your take on this? >> >> >> >> Kind regards, >> >> Stefan B=C3=BCringer >> >> >> >> P.S. I couldn't find that much on the internet regarding = Authorization Code >> >> Flow with PKCE in SPAs, if you have some recommendations for good = blog posts >> >> I would be grateful. >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth = >> >> >> > >> > >> > >> > -- >> > Bill Burke >> > Red Hat >> > >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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=_10979C48-C6D2-4677-B2DE-3183712D3C1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =10Why not using http-only cookies instead of refresh = tokens?
If the app can interact with AuthZ server through = a hidden iframe with prompt=3Dnone param, you shouldn=E2=80=99t need = refresh tokens.

If your SAP is running on a different domain with the backend = server, Safari=E2=80=99s Intelligent Tracking Prevention will break the = hidden iframe way though.

On = Sep 20, 2017, at 7:32, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Right, =  Refresh token is bearer for native apps, that is why we came up = with PKCE to protect code.

For Angular the code flow with PKCE is probably better than = the token response type.   

However with bearer tokens it is still = riskier than code with a confidential client so the AS should take that = into account and not allow refresh tokens to live forever.

One future way to = protect refresh tokens and perhaps Access tokens is to use token binding = to bind the tokens to the user agent.   You could do that now for = refresh tokens in Edge (Chrome has TB off by default still). =  

I think = more work needs to be done to come up with a best practice for = SPA.

John = B.

On Sep 19, 2017, at 7:02 PM, = Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Only for confidential clients.  No authentication is = required for public clients.

On Tue, Sep 19, 2017 at 4:47 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Except a refresh token = is not purely bearer. The client is required to authenticate to use = it.

Phil

> On Sep 19, 2017, at 2:33 PM, Bill Burke <bburke@redhat.com> = wrote:
>
> I'd be curious to the response to this too.
>
> Seems to me that refresh token has the same possible security risks = in
> an Angular app as an access token, except the refresh token is = valid
> longer....Still, if you did the implicit flow, you'd have to = have
> longer access token timeouts as it would be really annoying for = the
> user to have to login again and again in a long session with = your
> Angular app.
>
> We have a javascript adapter that does Authz Code Flow with PKCE = for
> our Angular app.  It also does CORS checks on the code to = token XHR
> request just in case on the IDP side.
>
>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer <sbueringer@gmail.com> wrote:
>> Hi,
>>
>> there were some discussions in January regarding = recommendations for
>> browser-based apps
>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>>
>> I'd just like to ask if the Authorization Code Flow with PKCE = is a valid
>> option for Single-Page-Applications (in our case Angular), = because Implicit
>> Flow cannot be used in our scenario.
>>
>> Authorization Code Flow with PKCE eliminates the necessity for = client
>> secrets, but our concern is that exposing the refresh token to = the SPA might
>> be a security risk, compared to the Implicit Flow were no = refresh token is
>> exposed.
>>
>> What's your take on this?
>>
>> Kind regards,
>> Stefan B=C3=BCringer
>>
>> P.S. I couldn't find that much on the internet regarding = Authorization Code
>> Flow with PKCE in SPAs, if you have some recommendations for = good blog posts
>> I would be grateful.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

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

= --Apple-Mail=_10979C48-C6D2-4677-B2DE-3183712D3C1C-- From nobody Tue Sep 19 17:44:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA72C133023 for ; Tue, 19 Sep 2017 17:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 QbKjM14QeXde for ; Tue, 19 Sep 2017 17:44:56 -0700 (PDT) Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91031326ED for ; Tue, 19 Sep 2017 17:44:56 -0700 (PDT) Received: by mail-vk0-f51.google.com with SMTP id o22so677417vke.1 for ; Tue, 19 Sep 2017 17:44:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=z3FTy7o3UTglWK6CIX+UCSYd5G2EnoJnW+2FsWeFvyo=; b=o0B3vmVFjiviqsxkfRiCVR864RBAqU4/nTvL3Cp+qFJW3pESgdLxKPcGhWy+5l1Wj/ epZskDr+eiXdbldyC4H4fnph8lKODDj4JNPUYWiif72yiZbcXPHjlUkN7fQwD5zXVtyV 9RXFEyckervyjIiNV9iolHaFMDIOm9s3W+Mdsd/6AdWKUQ3ASLvObBiwpuvfJ0mJQbYx 5Qqr1ZdKTiXBirJXQ/oeeHlz9iC3NnUzJer5TcVjsjIPJYcHzUyUaE/S1cW10SXp+E29 VL0CMu6XMkPFhs4onAs3//ZH9MtutqTnvWh/PflNps+BSYvuZCnoQ/mIjRvE0G+oTusx SELQ== X-Gm-Message-State: AHPjjUjjNNALSctqgv4Guh94VqxpTpaXyXJ1+4dMNBZhrYPzejddVarO iUx67YOLsnyG7UaAzuo5CjEeY7UbjT0E/uZKLfYcag== X-Google-Smtp-Source: AOwi7QDmK7utDzzZ7OdTXvHRfpIBVTpuPCEUrrjCH3x6BPvsAVCuFjNVbUq8s4bzKCtAVmK+IIQY4maPDlhvZmoi6yY= X-Received: by 10.31.192.70 with SMTP id q67mr2524196vkf.28.1505868295552; Tue, 19 Sep 2017 17:44:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.55.79 with HTTP; Tue, 19 Sep 2017 17:44:55 -0700 (PDT) In-Reply-To: <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> From: Bill Burke Date: Tue, 19 Sep 2017 20:44:55 -0400 Message-ID: To: nov matake Cc: John Bradley , OAuth WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 00:44:59 -0000 Cookies are vulnerable to CXRF. On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: > Why not using http-only cookies instead of refresh tokens? > If the app can interact with AuthZ server through a hidden iframe with > prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. > > If your SAP is running on a different domain with the backend server, > Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden if= rame way > though. > > On Sep 20, 2017, at 7:32, John Bradley wrote: > > Right, Refresh token is bearer for native apps, that is why we came up w= ith > PKCE to protect code. > > For Angular the code flow with PKCE is probably better than the token > response type. > > However with bearer tokens it is still riskier than code with a confident= ial > client so the AS should take that into account and not allow refresh toke= ns > to live forever. > > One future way to protect refresh tokens and perhaps Access tokens is to = use > token binding to bind the tokens to the user agent. You could do that n= ow > for refresh tokens in Edge (Chrome has TB off by default still). > > I think more work needs to be done to come up with a best practice for SP= A. > > John B. > > On Sep 19, 2017, at 7:02 PM, Adam Lewis > wrote: > > Only for confidential clients. No authentication is required for public > clients. > > On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) > wrote: >> >> Except a refresh token is not purely bearer. The client is required to >> authenticate to use it. >> >> Phil >> >> > On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >> > >> > I'd be curious to the response to this too. >> > >> > Seems to me that refresh token has the same possible security risks in >> > an Angular app as an access token, except the refresh token is valid >> > longer....Still, if you did the implicit flow, you'd have to have >> > longer access token timeouts as it would be really annoying for the >> > user to have to login again and again in a long session with your >> > Angular app. >> > >> > We have a javascript adapter that does Authz Code Flow with PKCE for >> > our Angular app. It also does CORS checks on the code to token XHR >> > request just in case on the IDP side. >> > >> >> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer >> >> wrote: >> >> Hi, >> >> >> >> there were some discussions in January regarding recommendations for >> >> browser-based apps >> >> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). >> >> >> >> I'd just like to ask if the Authorization Code Flow with PKCE is a >> >> valid >> >> option for Single-Page-Applications (in our case Angular), because >> >> Implicit >> >> Flow cannot be used in our scenario. >> >> >> >> Authorization Code Flow with PKCE eliminates the necessity for client >> >> secrets, but our concern is that exposing the refresh token to the SP= A >> >> might >> >> be a security risk, compared to the Implicit Flow were no refresh tok= en >> >> is >> >> exposed. >> >> >> >> What's your take on this? >> >> >> >> Kind regards, >> >> Stefan B=C3=BCringer >> >> >> >> P.S. I couldn't find that much on the internet regarding Authorizatio= n >> >> Code >> >> Flow with PKCE in SPAs, if you have some recommendations for good blo= g >> >> posts >> >> I would be grateful. >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > >> > >> > >> > -- >> > Bill Burke >> > Red Hat >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Bill Burke Red Hat From nobody Tue Sep 19 18:32:03 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B794B1320DC for ; Tue, 19 Sep 2017 18:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZcP4YZoFZXHc for ; Tue, 19 Sep 2017 18:31:58 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5161321AC for ; Tue, 19 Sep 2017 18:31:58 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id p5so821546pgn.7 for ; Tue, 19 Sep 2017 18:31: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=sRN9VgI19d/moiEgqjIoVgMh1F6k+bS2t7JCZedAlew=; b=paRlqQJtMV2E/6/cdfC7L4GoptL+KUqqs3orWTvkRLdGpNhzyY9q458PCykYxrRWN2 fJ6mct3nnx3iW6STLtZhSo0YaZeM/TKv5WqTmWTpR+MmO2ZKzOaJmIKsFGFFhPYHUxVz b0JZTnSUK7vtEKwrv+oc3aYrv5AEu98mtG16A/8wBdRZS9i7LwDpsCxLGG2s1kE5ym0F eY3c6FfIJd8/CXN45tbMhv5f1XWSytF8mRGVzO0qOutAWYgOm/gLyOJ827M13uGNH+KQ hHpi7zDCkVpkyrYrWUV+K7BFdeXOrzNSrLuQF00YJ0Z0IegurM0dPjKnCDS5JEJtnc/r EPUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sRN9VgI19d/moiEgqjIoVgMh1F6k+bS2t7JCZedAlew=; b=K5N2FUdFVTkaXefrhqThMsHkyUwy12vsgEGHz8qCaTMnUB4tlCmYf5X8tY+nV13iBQ idcqqNgFePejnHI46je4lNRVhWpYTYEQvYYJXRepnyPTMHuQJSJxcIbJXUQsXEbz8F2f PNzArmS0lmzKH8vUslYeki2QeA5ZgiqQyXCOyG0+GGyU0TINX8DosUoam3m8pjtovy8g TAhOT0C06/Vvp0BfMNjfA+0gnxe4S1esADN1PQl6qycHNhZx1EPUitiUxrAGgUu8rf+x ap/9HZvcswNG3Jc4bzCWcjvykSc1yVA1wD0czefdSDPOAPgEI/F95zoVQ06BXEJzwcWk wsxQ== X-Gm-Message-State: AHPjjUg0Yovb8Z748gRXnxKcOzrhd4QMbtKbvR3gB1I0DKsIMHsg4L9y HohA6Iv3ZVGt/UwdvWrN5ZgX8o8/Kdc= X-Google-Smtp-Source: AOwi7QD6dIYC515eEUO07kyCuncktPgZKI4FhnF6k5igOuy0VhzJL2m4LJy+nhlBwcShSeK/1RntQg== X-Received: by 10.98.178.133 with SMTP id z5mr499154pfl.312.1505871117156; Tue, 19 Sep 2017 18:31:57 -0700 (PDT) Received: from [10.3.48.101] (mobile-166-170-38-115.mycingular.net. [166.170.38.115]) by smtp.gmail.com with ESMTPSA id n10sm5883209pfh.121.2017.09.19.18.31.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 18:31:54 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3FF7B216-0132-4FF0-B3F0-1EC887A08862 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 20 Sep 2017 09:31:48 +0800 Cc: nov matake , OAuth WG Content-Transfer-Encoding: 7bit Message-Id: <1A823C26-FC05-48C1-A2E1-7B2B6A2607BB@manicode.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> To: Bill Burke Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 01:32:02 -0000 --Apple-Mail-3FF7B216-0132-4FF0-B3F0-1EC887A08862 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not always, Bill. There is a new standard called "same site cookies" or "fir= st party cookies" that allows you to programmatically remove this risk in so= me modern browsers, it's worth reviewing.=20 https://tools.ietf.org/html/draft-west-first-party-cookies-07 It's live in Chrome and Opera and will only grow in support. http://caniuse.= com/#search=3Dsamesite Jim > On Sep 20, 2017, at 8:44 AM, Bill Burke wrote: >=20 > Cookies are vulnerable to CXRF. >=20 >> On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: >> Why not using http-only cookies instead of refresh tokens? >> If the app can interact with AuthZ server through a hidden iframe with >> prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. >>=20 >> If your SAP is running on a different domain with the backend server, >> Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden if= rame way >> though. >>=20 >> On Sep 20, 2017, at 7:32, John Bradley wrote: >>=20 >> Right, Refresh token is bearer for native apps, that is why we came up w= ith >> PKCE to protect code. >>=20 >> For Angular the code flow with PKCE is probably better than the token >> response type. >>=20 >> However with bearer tokens it is still riskier than code with a confident= ial >> client so the AS should take that into account and not allow refresh toke= ns >> to live forever. >>=20 >> One future way to protect refresh tokens and perhaps Access tokens is to u= se >> token binding to bind the tokens to the user agent. You could do that n= ow >> for refresh tokens in Edge (Chrome has TB off by default still). >>=20 >> I think more work needs to be done to come up with a best practice for SP= A. >>=20 >> John B. >>=20 >> On Sep 19, 2017, at 7:02 PM, Adam Lewis >> wrote: >>=20 >> Only for confidential clients. No authentication is required for public >> clients. >>=20 >> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) >> wrote: >>>=20 >>> Except a refresh token is not purely bearer. The client is required to >>> authenticate to use it. >>>=20 >>> Phil >>>=20 >>>> On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >>>>=20 >>>> I'd be curious to the response to this too. >>>>=20 >>>> Seems to me that refresh token has the same possible security risks in >>>> an Angular app as an access token, except the refresh token is valid >>>> longer....Still, if you did the implicit flow, you'd have to have >>>> longer access token timeouts as it would be really annoying for the >>>> user to have to login again and again in a long session with your >>>> Angular app. >>>>=20 >>>> We have a javascript adapter that does Authz Code Flow with PKCE for >>>> our Angular app. It also does CORS checks on the code to token XHR >>>> request just in case on the IDP side. >>>>=20 >>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer >>>>> wrote: >>>>> Hi, >>>>>=20 >>>>> there were some discussions in January regarding recommendations for >>>>> browser-based apps >>>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). >>>>>=20 >>>>> I'd just like to ask if the Authorization Code Flow with PKCE is a >>>>> valid >>>>> option for Single-Page-Applications (in our case Angular), because >>>>> Implicit >>>>> Flow cannot be used in our scenario. >>>>>=20 >>>>> Authorization Code Flow with PKCE eliminates the necessity for client >>>>> secrets, but our concern is that exposing the refresh token to the SPA= >>>>> might >>>>> be a security risk, compared to the Implicit Flow were no refresh toke= n >>>>> is >>>>> exposed. >>>>>=20 >>>>> What's your take on this? >>>>>=20 >>>>> Kind regards, >>>>> Stefan B=C3=BCringer >>>>>=20 >>>>> P.S. I couldn't find that much on the internet regarding Authorization= >>>>> Code >>>>> Flow with PKCE in SPAs, if you have some recommendations for good blog= >>>>> posts >>>>> I would be grateful. >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Bill Burke >>>> Red Hat >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 > Bill Burke > Red Hat >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3FF7B216-0132-4FF0-B3F0-1EC887A08862 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not always, Bill. There is a new stand= ard called "same site cookies" or "first party cookies" that allows you to p= rogrammatically remove this risk in some modern browsers, it's worth reviewi= ng. 


It's live in Chrome and Opera and will only gr= ow in support. http:/= /caniuse.com/#search=3Dsamesite

Jim
<= br>

On Sep 20, 2017, at 8:44 AM, Bill Bu= rke <bburke@redhat.com> wrote= :

Cookies are vulnerable t= o CXRF.

On Tue, Sep 19, 2017 at 7:48 PM, no= v matake <matake@gmail.com> wr= ote:
Why not using http-only cooki= es instead of refresh tokens?
If the app can interact with AuthZ server through a hidden iframe w= ith
prompt=3Dnone par= am, you shouldn=E2=80=99t need refresh tokens.

= If your SAP is running on a different domain with the backend server,<= /span>
Safari=E2=80=99s Inte= lligent Tracking Prevention will break the hidden iframe way
though.

On Sep 20, 2017, at 7:32, John Bradley <ve7jtb@ve7jtb.com> wrote:

Right,  Refresh token is bearer for native apps, that is why we came= up with
PKCE to prot= ect code.

=
For Angular the code flow with P= KCE is probably better than the token
response type.

However w= ith bearer tokens it is still riskier than code with a confidential
client so the AS should take t= hat into account and not allow refresh tokens
to live forever.

One future way to protect refresh tokens and perhaps Access tokens is to us= e
token binding to bi= nd the tokens to the user agent.   You could do that now
for refresh tokens in Edge (Ch= rome has TB off by default still).

I think= more work needs to be done to come up with a best practice for SPA.<= br>

John B.

On Sep 1= 9, 2017, at 7:02 PM, Adam Lewis <adam.lewis@motorolasolutions.com>
=
wrote:

On= ly for confidential clients.  No authentication is required for public<= /span>
clients.

On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <= phil.hunt@oracle.com><= br>
wrote:

Except a refresh token is not purely bearer. The client is required to
authenticate to use it.
=

Phil

On Sep 1= 9, 2017, at 2:33 PM, Bill Burke <bbu= rke@redhat.com> wrote:

I'd be c= urious to the response to this too.

S= eems to me that refresh token has the same possible security risks in=
an Angular app as an acce= ss token, except the refresh token is valid
longer....Still, if you did the implicit flow, you'= d have to have
longe= r access token timeouts as it would be really annoying for the
user to have to login again and a= gain in a long session with your
Angular app.
<= blockquote type=3D"cite">

We have a j= avascript adapter that does Authz Code Flow with PKCE for
our Angular app.  It also does C= ORS checks on the code to token XHR
request just in case on the IDP side.

On Tue, Sep 19, 2017 at 9:27 AM,= Stefan B=C3=BCringer <sbueringer= @gmail.com>
wrote:
Hi,<= br>

=
there were some discussions in January reg= arding recommendations for
=
browser-based apps
=
(https://www.ietf.org/mail-archive/web/oauth/current/msg16874.ht= ml).

I'd just like to ask if th= e Authorization Code Flow with PKCE is a
valid
option for Single-Page-Applications (in our case Angular), becaus= e
Implicit
Flow cannot be used in our= scenario.
<= blockquote type=3D"cite">
Authorization Code Flow w= ith PKCE eliminates the necessity for client
secrets, bu= t our concern is that exposing the refresh token to the SPA
might
be a security risk, compared to the Implicit Fl= ow were no refresh token
is
exposed.=

What's your take on this?

<= blockquote type=3D"cite">
Kind regards,
Stefan B=C3= =BCringer

P.S. I couldn't find that= much on the internet regarding Authorization
Code=
Flow with PKCE in SPAs, if you have some recommendations for go= od blog
posts
I would be grateful.

_____________________________________= __________
<= blockquote type=3D"cite">OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth

=



--
Bill Burke
Red Hat

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

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


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


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



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




= --
Bill Burke
Red Hat

_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-3FF7B216-0132-4FF0-B3F0-1EC887A08862-- From nobody Tue Sep 19 19:11:36 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFAE126DD9 for ; Tue, 19 Sep 2017 19:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Kvy4N4b8vIdj for ; Tue, 19 Sep 2017 19:11:33 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B351124B18 for ; Tue, 19 Sep 2017 19:11:32 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id d8so875373pgt.4 for ; Tue, 19 Sep 2017 19:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lVuvYW22uVq88wpaX6UA8vyBx6VKzHhZMIkzU3OGOZQ=; b=ou07PxyDok8gw1+0cabI0Qe2R0W5Rll7XwG/VZo8eWE2OC/GCKVyIemvPU7jhjH1jI C4C6PhTNR+ap4GX25F8uv+JIWVB/4qNNbgrsPBm9wtfR4YnR4g7SSDfTJGn8ljz1oeua UsyHQj/RUCTq3Nz9dLNf57mS0YwMcQ/ciBerYXQoh/6ZBimzmHQt0nhdn+4DyKsGbEWH LZiMHVTSQGvnotVlo0h8mnMxCjDJEWqwLYztbbR8cjBVAyydnFYdkm2U8JTSIrVeBnk7 6RLTS5v79GD61BhrO8aqzmoCzWVbbV80A8iesRha7IrAXdNEHNlGbEWR6Zd2RnOSJtq+ GM6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lVuvYW22uVq88wpaX6UA8vyBx6VKzHhZMIkzU3OGOZQ=; b=iUn1AWAEGTLq96wG7z7WWl/dRlVWhvmFa3L6adHg/SHagdf6h+TxI6ubsbpHcJ8GCr tr0YIwGinyfl5jdIIq/aa5b2HU/6vW99RvhmfTPKmCh5J/rpon+0s3gB2P2Ra5yf7I+x ASmOwX3IgwBao/DSsFTWZP/oC+PO/0jRuSau6ELbg+8hsTVRVBywdXwwq5cxcJhCErtH 8/JkhUaQAVj03tOafHxruGW9Y9J0gV+aUq5euRJGkJyyNmFN2hlcOuz6ajqgOsK7dlii PtN9wJQbIrWWhcGpmrh0/J7y58zINSbo4gu+wdAeMKkeMs48ILA7MWSGMKv/x2LFB0hO Nn8A== X-Gm-Message-State: AHPjjUgoWzAhrupzbCrzqC4uL5yrPbyfeSBVisNa/pCA20NpDoGmd2iB O5PPAv//VYVAk0iQwsiO07JyCdZM X-Google-Smtp-Source: AOwi7QCnNcBEo9fIlH23FYTsilNnwYn2JuTp7KSlQQznnNnhy+O9+gSycWEpx6Yj8PRTAVvRb6Gm7g== X-Received: by 10.98.207.134 with SMTP id b128mr593465pfg.202.1505873492204; Tue, 19 Sep 2017 19:11:32 -0700 (PDT) Received: from [100.88.219.90] (1.69.239.49.rev.vmobile.jp. [49.239.69.1]) by smtp.gmail.com with ESMTPSA id o17sm5124643pfa.22.2017.09.19.19.11.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 19:11:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Nov Matake X-Mailer: iPhone Mail (15A372) In-Reply-To: Date: Wed, 20 Sep 2017 11:11:29 +0900 Cc: John Bradley , OAuth WG Content-Transfer-Encoding: quoted-printable Message-Id: <22DCF344-9723-453C-B997-9475521C3777@gmail.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> To: Bill Burke Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 02:11:35 -0000 you have redirect uri restriction there. nov > On Sep 20, 2017, at 9:44, Bill Burke wrote: >=20 > Cookies are vulnerable to CXRF. >=20 >> On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: >> Why not using http-only cookies instead of refresh tokens? >> If the app can interact with AuthZ server through a hidden iframe with >> prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. >>=20 >> If your SAP is running on a different domain with the backend server, >> Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden if= rame way >> though. >>=20 >> On Sep 20, 2017, at 7:32, John Bradley wrote: >>=20 >> Right, Refresh token is bearer for native apps, that is why we came up w= ith >> PKCE to protect code. >>=20 >> For Angular the code flow with PKCE is probably better than the token >> response type. >>=20 >> However with bearer tokens it is still riskier than code with a confident= ial >> client so the AS should take that into account and not allow refresh toke= ns >> to live forever. >>=20 >> One future way to protect refresh tokens and perhaps Access tokens is to u= se >> token binding to bind the tokens to the user agent. You could do that n= ow >> for refresh tokens in Edge (Chrome has TB off by default still). >>=20 >> I think more work needs to be done to come up with a best practice for SP= A. >>=20 >> John B. >>=20 >> On Sep 19, 2017, at 7:02 PM, Adam Lewis >> wrote: >>=20 >> Only for confidential clients. No authentication is required for public >> clients. >>=20 >> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) >> wrote: >>>=20 >>> Except a refresh token is not purely bearer. The client is required to >>> authenticate to use it. >>>=20 >>> Phil >>>=20 >>>> On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >>>>=20 >>>> I'd be curious to the response to this too. >>>>=20 >>>> Seems to me that refresh token has the same possible security risks in >>>> an Angular app as an access token, except the refresh token is valid >>>> longer....Still, if you did the implicit flow, you'd have to have >>>> longer access token timeouts as it would be really annoying for the >>>> user to have to login again and again in a long session with your >>>> Angular app. >>>>=20 >>>> We have a javascript adapter that does Authz Code Flow with PKCE for >>>> our Angular app. It also does CORS checks on the code to token XHR >>>> request just in case on the IDP side. >>>>=20 >>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer >>>>> wrote: >>>>> Hi, >>>>>=20 >>>>> there were some discussions in January regarding recommendations for >>>>> browser-based apps >>>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). >>>>>=20 >>>>> I'd just like to ask if the Authorization Code Flow with PKCE is a >>>>> valid >>>>> option for Single-Page-Applications (in our case Angular), because >>>>> Implicit >>>>> Flow cannot be used in our scenario. >>>>>=20 >>>>> Authorization Code Flow with PKCE eliminates the necessity for client >>>>> secrets, but our concern is that exposing the refresh token to the SPA= >>>>> might >>>>> be a security risk, compared to the Implicit Flow were no refresh toke= n >>>>> is >>>>> exposed. >>>>>=20 >>>>> What's your take on this? >>>>>=20 >>>>> Kind regards, >>>>> Stefan B=C3=BCringer >>>>>=20 >>>>> P.S. I couldn't find that much on the internet regarding Authorization= >>>>> Code >>>>> Flow with PKCE in SPAs, if you have some recommendations for good blog= >>>>> posts >>>>> I would be grateful. >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Bill Burke >>>> Red Hat >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 > Bill Burke > Red Hat From nobody Tue Sep 19 20:58:54 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079CB1321B6 for ; Tue, 19 Sep 2017 20:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1ve_pSOY_tX for ; Tue, 19 Sep 2017 20:58:49 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E34013219F for ; Tue, 19 Sep 2017 20:58:49 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id w9so1080621ywi.11 for ; Tue, 19 Sep 2017 20:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PpbckVBZ03xcGEIWydI19cYzTIgVW8eHYkNyTF1DxYM=; b=n0VWTMW2dWbuEPaOz6di3V9Dq1wFZ6ZLoI4mltekRR3RQLDOd98aQHqIyDKhJN3FrZ aVDNBgfor4YMXBeluMJ0yYqF5AVZfJqBrU35DyXM6Pi7fXR5CX3wplGaj5YG8R3ZInGC UzTmkh8++WR/1CuZzhTMl91M35ahUjUcoJtZtOJUat1swDuTUTVVtthOTz8ZRZIp+w4Z zZAHZfqsL/zpzvMhvvF+JbWb9u7SJXjHL9RgXiRYkgGDUFNpxOrC7kHSx3N4zVb0OZPi EH3SsoQkXSYIJpBOIuTjV0Q1ceoD7bLIQnVTfhST2Ky+XQ82TMuTI9BCWG2WrjgZ0mPl BAOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PpbckVBZ03xcGEIWydI19cYzTIgVW8eHYkNyTF1DxYM=; b=S8pE8NQ1NsglSnYlNrv64tZfDJySHBBywv8wjbJC3hpRmN15RDV9ZDiKHEzKTPH29t hB8PCeU0DDecow2mtMDGJ7EvcfrRnRvuXjKPFfXlEzB8dvzRw2QDQ3mtag9kcaYlDLp3 Pse0zlga+qlNe90T03uSTOQl8MIoR+/H63RnNSrxeGVLfxJEwj+VMnT3mX+Ryja3l31t 9RFA7HvYrbr+CI9rCX5gsuGd2dbCYVZEQUBcW5xg4RPr0+e6s0UNt3pDJSrhOi8R3ytw 514o5m+ctbSMD/O89hrV+GLBABrtF8Rjn32NKAJ5LJ6ewfxAGXbqhhOPQ2RFEE8L4VEk 5OTA== X-Gm-Message-State: AHPjjUiT+0no5FaNPovJKZv5ZUE7Nm34OE/udQEkJj++rBEWafR8AtWn tcptqySLZHOLgi0W/W08MpTyFzlrAVQcnr/wgYs= X-Google-Smtp-Source: AOwi7QC163ttePfXzsZW7bhv4FJztLMP3cgmQ2x6h/8ZX3wdHWJPfs0n8VUKqw1/iZ6BJtAFF7Da8dCDna59dYU2+wI= X-Received: by 10.37.186.197 with SMTP id a5mr2415829ybk.39.1505879928095; Tue, 19 Sep 2017 20:58:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.159.203 with HTTP; Tue, 19 Sep 2017 20:58:46 -0700 (PDT) Received: by 10.129.159.203 with HTTP; Tue, 19 Sep 2017 20:58:46 -0700 (PDT) In-Reply-To: <22DCF344-9723-453C-B997-9475521C3777@gmail.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> <22DCF344-9723-453C-B997-9475521C3777@gmail.com> From: Josh Mandel Date: Tue, 19 Sep 2017 23:58:46 -0400 Message-ID: To: Nov Matake Cc: Bill Burke , "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary="f403043df198304a56055996fed8" Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 03:58:53 -0000 --f403043df198304a56055996fed8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can anyone provide insight about what protection PKCE adds for browser based apps using the authorization code flow? The PKCE intro says that the specification is designed to mitigate an attack where: > the attacker intercepts the authorization code returned from the authorization endpoint within a communication path not protected by Transport Layer Security (TLS), such as inter-application communication within the client's operating system ... but for a browser based client, I'm not clear on why this is important. (I agree PKCE doesn't hurt, of course, but I'm trying to understand whether there is a specific advantage.) Thanks for any perspective that, Josh On Sep 19, 2017 21:11, "Nov Matake" wrote: > you have redirect uri restriction there. > > nov > > > On Sep 20, 2017, at 9:44, Bill Burke wrote: > > > > Cookies are vulnerable to CXRF. > > > >> On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: > >> Why not using http-only cookies instead of refresh tokens? > >> If the app can interact with AuthZ server through a hidden iframe with > >> prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. > >> > >> If your SAP is running on a different domain with the backend server, > >> Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden= iframe > way > >> though. > >> > >> On Sep 20, 2017, at 7:32, John Bradley wrote: > >> > >> Right, Refresh token is bearer for native apps, that is why we came u= p > with > >> PKCE to protect code. > >> > >> For Angular the code flow with PKCE is probably better than the token > >> response type. > >> > >> However with bearer tokens it is still riskier than code with a > confidential > >> client so the AS should take that into account and not allow refresh > tokens > >> to live forever. > >> > >> One future way to protect refresh tokens and perhaps Access tokens is > to use > >> token binding to bind the tokens to the user agent. You could do tha= t > now > >> for refresh tokens in Edge (Chrome has TB off by default still). > >> > >> I think more work needs to be done to come up with a best practice for > SPA. > >> > >> John B. > >> > >> On Sep 19, 2017, at 7:02 PM, Adam Lewis com> > >> wrote: > >> > >> Only for confidential clients. No authentication is required for publ= ic > >> clients. > >> > >> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) > >> wrote: > >>> > >>> Except a refresh token is not purely bearer. The client is required t= o > >>> authenticate to use it. > >>> > >>> Phil > >>> > >>>> On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: > >>>> > >>>> I'd be curious to the response to this too. > >>>> > >>>> Seems to me that refresh token has the same possible security risks = in > >>>> an Angular app as an access token, except the refresh token is valid > >>>> longer....Still, if you did the implicit flow, you'd have to have > >>>> longer access token timeouts as it would be really annoying for the > >>>> user to have to login again and again in a long session with your > >>>> Angular app. > >>>> > >>>> We have a javascript adapter that does Authz Code Flow with PKCE for > >>>> our Angular app. It also does CORS checks on the code to token XHR > >>>> request just in case on the IDP side. > >>>> > >>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer < > sbueringer@gmail.com> > >>>>> wrote: > >>>>> Hi, > >>>>> > >>>>> there were some discussions in January regarding recommendations fo= r > >>>>> browser-based apps > >>>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html)= . > >>>>> > >>>>> I'd just like to ask if the Authorization Code Flow with PKCE is a > >>>>> valid > >>>>> option for Single-Page-Applications (in our case Angular), because > >>>>> Implicit > >>>>> Flow cannot be used in our scenario. > >>>>> > >>>>> Authorization Code Flow with PKCE eliminates the necessity for clie= nt > >>>>> secrets, but our concern is that exposing the refresh token to the > SPA > >>>>> might > >>>>> be a security risk, compared to the Implicit Flow were no refresh > token > >>>>> is > >>>>> exposed. > >>>>> > >>>>> What's your take on this? > >>>>> > >>>>> Kind regards, > >>>>> Stefan B=C3=BCringer > >>>>> > >>>>> P.S. I couldn't find that much on the internet regarding > Authorization > >>>>> Code > >>>>> Flow with PKCE in SPAs, if you have some recommendations for good > blog > >>>>> posts > >>>>> I would be grateful. > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Bill Burke > >>>> Red Hat > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > -- > > Bill Burke > > Red Hat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --f403043df198304a56055996fed8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can anyone provide insight about what protection PKCE add= s for browser based apps using the authorization code flow? The PKCE intro = says that the specification is designed to mitigate an attack where:

> the attacker intercepts the aut= horization code returned from the authorization endpoint within a communica= tion path not protected by Transport Layer Security (TLS), such as inter-ap= plication communication within the client's operating system

... but for a browser based client= , I'm not clear on why this is important. (I agree PKCE doesn't hur= t, of course, but I'm trying to understand whether there is a specific = advantage.)=C2=A0

Thanks= for any perspective that,=C2=A0

Josh=C2=A0


On Sep 19, 2017 21:11, "Nov Matake" <matake@gmail.com> wrote:
you have redirect uri restriction there.<= br>
nov

> On Sep 20, 2017, at 9:44, Bill Burke <bburke@redhat.com> wrote:
>
> Cookies are vulnerable to CXRF.
>
>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake <matake@gmail.com> wrote:
>> Why not using http-only cookies instead of refresh tokens?
>> If the app can interact with AuthZ server through a hidden iframe = with
>> prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. >>
>> If your SAP is running on a different domain with the backend serv= er,
>> Safari=E2=80=99s Intelligent Tracking Prevention will break the hi= dden iframe way
>> though.
>>
>> On Sep 20, 2017, at 7:32, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>> Right,=C2=A0 Refresh token is bearer for native apps, that is why = we came up with
>> PKCE to protect code.
>>
>> For Angular the code flow with PKCE is probably better than the to= ken
>> response type.
>>
>> However with bearer tokens it is still riskier than code with a co= nfidential
>> client so the AS should take that into account and not allow refre= sh tokens
>> to live forever.
>>
>> One future way to protect refresh tokens and perhaps Access tokens= is to use
>> token binding to bind the tokens to the user agent.=C2=A0 =C2=A0Yo= u could do that now
>> for refresh tokens in Edge (Chrome has TB off by default still). >>
>> I think more work needs to be done to come up with a best practice= for SPA.
>>
>> John B.
>>
>> On Sep 19, 2017, at 7:02 PM, Adam Lewis <adam.lewis@motorolasolutions.com>=
>> wrote:
>>
>> Only for confidential clients.=C2=A0 No authentication is required= for public
>> clients.
>>
>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.hunt@oracle.com>
>> wrote:
>>>
>>> Except a refresh token is not purely bearer. The client is req= uired to
>>> authenticate to use it.
>>>
>>> Phil
>>>
>>>> On Sep 19, 2017, at 2:33 PM, Bill Burke <bburke@redhat.com> wrote:
>>>>
>>>> I'd be curious to the response to this too.
>>>>
>>>> Seems to me that refresh token has the same possible secur= ity risks in
>>>> an Angular app as an access token, except the refresh toke= n is valid
>>>> longer....Still, if you did the implicit flow, you'd h= ave to have
>>>> longer access token timeouts as it would be really annoyin= g for the
>>>> user to have to login again and again in a long session wi= th your
>>>> Angular app.
>>>>
>>>> We have a javascript adapter that does Authz Code Flow wit= h PKCE for
>>>> our Angular app.=C2=A0 It also does CORS checks on the cod= e to token XHR
>>>> request just in case on the IDP side.
>>>>
>>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer = <sbueringer@gmail.com> >>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> there were some discussions in January regarding recom= mendations for
>>>>> browser-based apps
>>>>> (https://www.i= etf.org/mail-archive/web/oauth/current/msg16874.html).
>>>>>
>>>>> I'd just like to ask if the Authorization Code Flo= w with PKCE is a
>>>>> valid
>>>>> option for Single-Page-Applications (in our case Angul= ar), because
>>>>> Implicit
>>>>> Flow cannot be used in our scenario.
>>>>>
>>>>> Authorization Code Flow with PKCE eliminates the neces= sity for client
>>>>> secrets, but our concern is that exposing the refresh = token to the SPA
>>>>> might
>>>>> be a security risk, compared to the Implicit Flow were= no refresh token
>>>>> is
>>>>> exposed.
>>>>>
>>>>> What's your take on this?
>>>>>
>>>>> Kind regards,
>>>>> Stefan B=C3=BCringer
>>>>>
>>>>> P.S. I couldn't find that much on the internet reg= arding Authorization
>>>>> Code
>>>>> Flow with PKCE in SPAs, if you have some recommendatio= ns for good blog
>>>>> posts
>>>>> I would be grateful.
>>>>>
>>>>> _______________________________________________ >>>>> OAuth mailing list
>>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/li= stinfo/oauth
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--f403043df198304a56055996fed8-- From nobody Tue Sep 19 22:21:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E104313308A for ; Tue, 19 Sep 2017 22:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAQX0SPg16X9 for ; Tue, 19 Sep 2017 22:21:43 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 9F903133063 for ; Tue, 19 Sep 2017 22:21:42 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id 108so1147767wra.5 for ; Tue, 19 Sep 2017 22:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gz7YpeC5UOYY8CemIJeHPOZ/db3pAHhrpGsmruI1LIM=; b=AhTZ973De319er6uh6JOki9P1yYdo+2fFNkLT/eBeaLq4K6b3hFYndDHccumvQec5o r5h1CaV66UY5e2FOaacRSed0Nk3GS72Ldi8dQCB7+oTSNv3phpq2kyJC+xBGTX2rbWM/ T5IxMM2k0/Yr6oCiFRQVoX/c7i8wLvi3Rya/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gz7YpeC5UOYY8CemIJeHPOZ/db3pAHhrpGsmruI1LIM=; b=TqzBQrELKpc0qtNKtR2NvWGiMdloBZrXTJ2calQIellB/JAxc2/hIdejgguILSrdDw fYr0xSm/V/8m8b9VCEnghk0IGePeRVCOAx8CLLcZIZNevOYvrg0UNVfP1Ya33OfixmyV pU4wG2ZVPPnxBaaDaZnGUEngd2hH/jXv7wjnmNYYvmtzPI7O8X7D1IeT9VL5Eyias45U SM3xfiPAX046Hs7SPHGsPLXaf/UkLUf2DV/FxKVCcv6eMXsIhW74V7lqocb9heIoRyz9 bKRMslbghBWyqx0K6p/r3u0VmEakK/gzYYf/Fk0xxRjN0OSVwxOoRqNl2n5YphHJXdpk nq5w== X-Gm-Message-State: AHPjjUg4Y+F+K8ner+YefOrpIwSnhYg06ti0cQljtOATtgo6MkmoIIZA GleiPSbwfCbwDhBy8mgVsXxqVy4GMcwT5ywQ95Txqkpqh5omhEzyIu889PSCX3iLfEPkpNPACcT l1rwuIxVnahI/RetupvftR4ELSSAnvstrR5ZsHil6Fpsvhs7BKT/GdYOSjOR6E9lF8w== X-Google-Smtp-Source: AOwi7QD+o5r/TNrLAjfDwaXgJwK0VF1fcEy1Kj+Gxhtuu3xNUmWtfopODP0IljMGbjdzKiN6vnMZRQ== X-Received: by 10.223.199.196 with SMTP id y4mr3461088wrg.181.1505884900610; Tue, 19 Sep 2017 22:21:40 -0700 (PDT) Received: from [192.168.1.2] (132.147.199.146.dyn.plus.net. [146.199.147.132]) by smtp.gmail.com with ESMTPSA id d9sm921924wrd.37.2017.09.19.22.21.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 22:21:39 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0A3125A8-3619-4FAD-A681-3CD32C86C302 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (14G60) In-Reply-To: <1A823C26-FC05-48C1-A2E1-7B2B6A2607BB@manicode.com> Date: Wed, 20 Sep 2017 06:21:38 +0100 Cc: Bill Burke , OAuth WG Content-Transfer-Encoding: 7bit Message-Id: <555F5261-7F4B-4BFD-8911-A8BFD675EE3F@forgerock.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> <1A823C26-FC05-48C1-A2E1-7B2B6A2607BB@manicode.com> To: Jim Manico Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 05:21:46 -0000 --Apple-Mail-0A3125A8-3619-4FAD-A681-3CD32C86C302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is this growing in support? It seems like a good idea, but when I reviewed i= t recently the draft had expired almost a year ago and still only Chrome and= Opera had implemented it. =46rom the outside it looks as if it has (inexpli= cably) died. Do you know if there is some activity happening behind the scen= es? -- Neil > On 20 Sep 2017, at 02:31, Jim Manico wrote: >=20 > Not always, Bill. There is a new standard called "same site cookies" or "f= irst party cookies" that allows you to programmatically remove this risk in s= ome modern browsers, it's worth reviewing.=20 >=20 > https://tools.ietf.org/html/draft-west-first-party-cookies-07 >=20 > It's live in Chrome and Opera and will only grow in support. http://canius= e.com/#search=3Dsamesite >=20 > Jim >=20 >=20 >> On Sep 20, 2017, at 8:44 AM, Bill Burke wrote: >>=20 >> Cookies are vulnerable to CXRF. >>=20 >>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: >>> Why not using http-only cookies instead of refresh tokens? >>> If the app can interact with AuthZ server through a hidden iframe with >>> prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. >>>=20 >>> If your SAP is running on a different domain with the backend server, >>> Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden i= frame way >>> though. >>>=20 >>> On Sep 20, 2017, at 7:32, John Bradley wrote: >>>=20 >>> Right, Refresh token is bearer for native apps, that is why we came up w= ith >>> PKCE to protect code. >>>=20 >>> For Angular the code flow with PKCE is probably better than the token >>> response type. >>>=20 >>> However with bearer tokens it is still riskier than code with a confiden= tial >>> client so the AS should take that into account and not allow refresh tok= ens >>> to live forever. >>>=20 >>> One future way to protect refresh tokens and perhaps Access tokens is to= use >>> token binding to bind the tokens to the user agent. You could do that n= ow >>> for refresh tokens in Edge (Chrome has TB off by default still). >>>=20 >>> I think more work needs to be done to come up with a best practice for S= PA. >>>=20 >>> John B. >>>=20 >>> On Sep 19, 2017, at 7:02 PM, Adam Lewis >>> wrote: >>>=20 >>> Only for confidential clients. No authentication is required for public= >>> clients. >>>=20 >>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) >>> wrote: >>>>=20 >>>> Except a refresh token is not purely bearer. The client is required to >>>> authenticate to use it. >>>>=20 >>>> Phil >>>>=20 >>>>> On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >>>>>=20 >>>>> I'd be curious to the response to this too. >>>>>=20 >>>>> Seems to me that refresh token has the same possible security risks in= >>>>> an Angular app as an access token, except the refresh token is valid >>>>> longer....Still, if you did the implicit flow, you'd have to have >>>>> longer access token timeouts as it would be really annoying for the >>>>> user to have to login again and again in a long session with your >>>>> Angular app. >>>>>=20 >>>>> We have a javascript adapter that does Authz Code Flow with PKCE for >>>>> our Angular app. It also does CORS checks on the code to token XHR >>>>> request just in case on the IDP side. >>>>>=20 >>>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer >>>>>> wrote: >>>>>> Hi, >>>>>>=20 >>>>>> there were some discussions in January regarding recommendations for >>>>>> browser-based apps >>>>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). >>>>>>=20 >>>>>> I'd just like to ask if the Authorization Code Flow with PKCE is a >>>>>> valid >>>>>> option for Single-Page-Applications (in our case Angular), because >>>>>> Implicit >>>>>> Flow cannot be used in our scenario. >>>>>>=20 >>>>>> Authorization Code Flow with PKCE eliminates the necessity for client= >>>>>> secrets, but our concern is that exposing the refresh token to the SP= A >>>>>> might >>>>>> be a security risk, compared to the Implicit Flow were no refresh tok= en >>>>>> is >>>>>> exposed. >>>>>>=20 >>>>>> What's your take on this? >>>>>>=20 >>>>>> Kind regards, >>>>>> Stefan B=C3=BCringer >>>>>>=20 >>>>>> P.S. I couldn't find that much on the internet regarding Authorizatio= n >>>>>> Code >>>>>> Flow with PKCE in SPAs, if you have some recommendations for good blo= g >>>>>> posts >>>>>> I would be grateful. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Bill Burke >>>>> Red Hat >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Bill Burke >> Red Hat >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-0A3125A8-3619-4FAD-A681-3CD32C86C302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is this growing in support?= It seems like a good idea, but when I reviewed it recently the draft had ex= pired almost a year ago and still only Chrome and Opera had implemented it. = =46rom the outside it looks as if it has (inexplicably) died. Do you know if= there is some activity happening behind the scenes?

-- Neil

On 20 Sep 2017, at 02:31, Jim Manico <jim@manicode.com> wrote:

Not always, Bill. There is a new standard called "= same site cookies" or "first party cookies" that allows you to programmatica= lly remove this risk in some modern browsers, it's worth reviewing. 


It's live in Chrome and Opera and will only grow in suppor= t. http://caniuse.com= /#search=3Dsamesite

Jim


On Sep 20, 2017, at 8:44 AM, Bill Burke <bburke@redhat.com> wrote:

Cookies are vulnerable to CXRF.

On Tue, Sep 19, 2017 at 7:48 PM, nov matake <= ;matake@gmail.com> wrote:<= br>
Why not using http-only cookies instead o= f refresh tokens?
If t= he app can interact with AuthZ server through a hidden iframe with
prompt=3Dnone param, you shoul= dn=E2=80=99t need refresh tokens.

If your= SAP is running on a different domain with the backend server,
Safari=E2=80=99s Intelligent Track= ing Prevention will break the hidden iframe way
though.

On Sep 2= 0, 2017, at 7:32, John Bradley <ve7j= tb@ve7jtb.com> wrote:

Right,  = ;Refresh token is bearer for native apps, that is why we came up with=
PKCE to protect code.

For Angular the code flow with PKCE is probabl= y better than the token
response type.

However with bearer tok= ens it is still riskier than code with a confidential
client so the AS should take that into acco= unt and not allow refresh tokens
to live forever.

One future w= ay to protect refresh tokens and perhaps Access tokens is to use
<= /blockquote>
token binding to bind the tokens= to the user agent.   You could do that now
for refresh tokens in Edge (Chrome has TB o= ff by default still).

I think more work n= eeds to be done to come up with a best practice for SPA.

John B.

On Sep 19, 2017, a= t 7:02 PM, Adam Lewis <adam.lewis@motorolasolutions.com>
wrote:

Only for con= fidential clients.  No authentication is required for public
=
clients.

On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.hunt@oracle.com>
wrote:

Except a= refresh token is not purely bearer. The client is required to
<= span>authenticate to use it.

Phil

=
On Sep 19, 2017, a= t 2:33 PM, Bill Burke <bburke@redhat= .com> wrote:

I'd be curious to= the response to this too.
=

Seems to me= that refresh token has the same possible security risks in
an Angular app as an access token, ex= cept the refresh token is valid
longer....Still, if you did the implicit flow, you'd have to ha= ve
longer access to= ken timeouts as it would be really annoying for the
<= /blockquote>
user to have to login again and again in a l= ong session with your
Angular app.

We have a javascript a= dapter that does Authz Code Flow with PKCE for
our Angular app.  It also does CORS checks o= n the code to token XHR
<= span>request just in case on the IDP side.

=
On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3= =BCringer <sbueringer@gmail.com>
wrote:
Hi,

there were some discussions in January regarding reco= mmendations for
browser-based apps
(= https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).

I'd just like to ask if the Authoriza= tion Code Flow with PKCE is a
valid
= option for Single-Page-Applications (in our case Angular), because
Implicit
Flow cannot be used in our scenario.<= /span>

Authorization Code Flow with PKCE eli= minates the necessity for client
secrets, but our concer= n is that exposing the refresh token to the SPA
might
be a security risk, compared to the Implicit Flow were no r= efresh token
<= blockquote type=3D"cite">
is
exposed.
<= /blockquote>

What's your take on this?
=
Kind regards,
Stefan B=C3=BCringer<= /span>

P.S. I couldn't find that much on the= internet regarding Authorization
Code
Flow with PKCE in SPAs, if you have some recommendations for good blog
posts
I would be grateful.
<= /blockquote>

______________________________________________= _
OAuth mailing list
=
OAuth@ietf.org
<= blockquote type=3D"cite">
https://www.ietf.org/mailman/listinfo/o= auth


=

<= /blockquote>
--
Bill Burke
=
Red Hat

________= _______________________________________
=
OAuth mailing list
=
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

<= blockquote type=3D"cite">
___________________= ____________________________
OAuth mailing list
=
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth


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


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


<= blockquote type=3D"cite">
_______________________________________________
OAuth mailing list
OAuth@= ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth




--
Bill Burke
Red Hat

_______________________________________________
OAuth mailing list
OAuth= @ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_________= ______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.i= etf.org/mailman/listinfo/oauth
= --Apple-Mail-0A3125A8-3619-4FAD-A681-3CD32C86C302-- From nobody Tue Sep 19 23:49:56 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E0F13219F for ; Tue, 19 Sep 2017 23:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 S7zqqCmcM7pp for ; Tue, 19 Sep 2017 23:49:52 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28916133044 for ; Tue, 19 Sep 2017 23:49:52 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id b70so1089571pfl.8 for ; Tue, 19 Sep 2017 23:49:52 -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=5z6IZ0Hl4oL5Rw10KiSAbb3BBhSeRaCBolfve1tXZrQ=; b=YV4KPO6L4XG582MSam5gkiiHg9nb2ZWOmKrr+kN+p/87p1o/paw09cHfQtykZ9iaxW I2znoiRKc/XA7DLiJvTlmXwBjtocWL7l0K22CNdq0DiBKqetEYE0u8a6WcCn+cY1YQp2 kVs2hBKGLEwpXaabALscFwXq8MQLzRHfNfK8ZzQwfVq4Gpvbsy4NUmPi9X63d5HJLsJo MabkHHs8k9yADxUR+Z+SDEaIb6eh5WxpaTknb3ZzDvuqzTsDgQvLOOSTcVpi1CnNF7iv PQmlG8BJrqbdHCTGgV8Sn3l7R2lIL3hoxZ51k4HO1RNDAxLTRQSPehuRr9EvMjZgMJZB VXWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5z6IZ0Hl4oL5Rw10KiSAbb3BBhSeRaCBolfve1tXZrQ=; b=GIxDLJ/IQVEQjasGZZmwBaugB81cUFrQtJcaviwL1PNtLghP+RYMUJ+yQgeeY5T5NW IGFbRe8+Pk9cmPnuDCTPyWX7w7jzOA5AtUjLbV+qXYsy4TuzG+GBXVbuzH5QZNS5DCX6 IEMwMomrVHHWkqv0QicS+KV1N3pdJzYEZAomlkweb8xFjsYStgnSzw4xyYflrVeaKOAD XxD0uBvLVmTheFT3GxmA7QVa/AjQLo74cwV3+nUL6oGYkbg8huKpT0PO3dO6r0H/6BH7 peh2QQ9Jiv+CRQ6gTLIEVU5TmTVX9J7xkkNBGeB4kJHGMAjPoOp8DrxRADVDqIGzMWt4 Vqmw== X-Gm-Message-State: AHPjjUjp54a7pq1OBnH1dRUjkycFrQWL22+6Un9QPI92WJX1fdiTXMEP a/NjicsUfukJfv0BfmQswCdShshGro4= X-Google-Smtp-Source: AOwi7QAcBFSmuwCDIGOZm9fa7ysHQibqQyzrY6NovtX1OJp7YNhtqoFIcqwHO8jYhvoEgGpdHB5gww== X-Received: by 10.99.109.142 with SMTP id i136mr1144551pgc.353.1505890191114; Tue, 19 Sep 2017 23:49:51 -0700 (PDT) Received: from [172.19.248.94] ([104.153.224.167]) by smtp.gmail.com with ESMTPSA id x28sm6090829pgc.91.2017.09.19.23.49.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 23:49:49 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1AFBC675-E2C8-4178-99EC-DC56015D29CB Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14G60) In-Reply-To: <555F5261-7F4B-4BFD-8911-A8BFD675EE3F@forgerock.com> Date: Wed, 20 Sep 2017 14:49:38 +0800 Cc: Bill Burke , OAuth WG Content-Transfer-Encoding: 7bit Message-Id: <88292BDF-CAB6-4EA2-BDF0-11FEE4811E86@manicode.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> <1A823C26-FC05-48C1-A2E1-7B2B6A2607BB@manicode.com> <555F5261-7F4B-4BFD-8911-A8BFD675EE3F@forgerock.com> To: Neil Madden Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 06:49:55 -0000 --Apple-Mail-1AFBC675-E2C8-4178-99EC-DC56015D29CB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable While we did see android support in January 2017, Chrome and Opera only offe= red support a few months ago. FireFox has a bug on this with notes suggestin= g it will be rolled out in a year or so. And while the original RFC expired,= it's being rolled into the cookie RFC per my understanding. I also asked the author of this standard for additional commentary, I'll get= back to you. -- Jim Manico @Manicode > On Sep 20, 2017, at 1:21 PM, Neil Madden wrote= : >=20 > Is this growing in support? It seems like a good idea, but when I reviewed= it recently the draft had expired almost a year ago and still only Chrome a= nd Opera had implemented it. =46rom the outside it looks as if it has (inexp= licably) died. Do you know if there is some activity happening behind the sc= enes? >=20 > -- Neil >=20 >> On 20 Sep 2017, at 02:31, Jim Manico wrote: >>=20 >> Not always, Bill. There is a new standard called "same site cookies" or "= first party cookies" that allows you to programmatically remove this risk in= some modern browsers, it's worth reviewing.=20 >>=20 >> https://tools.ietf.org/html/draft-west-first-party-cookies-07 >>=20 >> It's live in Chrome and Opera and will only grow in support. http://caniu= se.com/#search=3Dsamesite >>=20 >> Jim >>=20 >>=20 >>> On Sep 20, 2017, at 8:44 AM, Bill Burke wrote: >>>=20 >>> Cookies are vulnerable to CXRF. >>>=20 >>>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: >>>> Why not using http-only cookies instead of refresh tokens? >>>> If the app can interact with AuthZ server through a hidden iframe with >>>> prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. >>>>=20 >>>> If your SAP is running on a different domain with the backend server, >>>> Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden i= frame way >>>> though. >>>>=20 >>>> On Sep 20, 2017, at 7:32, John Bradley wrote: >>>>=20 >>>> Right, Refresh token is bearer for native apps, that is why we came up= with >>>> PKCE to protect code. >>>>=20 >>>> For Angular the code flow with PKCE is probably better than the token >>>> response type. >>>>=20 >>>> However with bearer tokens it is still riskier than code with a confide= ntial >>>> client so the AS should take that into account and not allow refresh to= kens >>>> to live forever. >>>>=20 >>>> One future way to protect refresh tokens and perhaps Access tokens is t= o use >>>> token binding to bind the tokens to the user agent. You could do that= now >>>> for refresh tokens in Edge (Chrome has TB off by default still). >>>>=20 >>>> I think more work needs to be done to come up with a best practice for S= PA. >>>>=20 >>>> John B. >>>>=20 >>>> On Sep 19, 2017, at 7:02 PM, Adam Lewis >>>> wrote: >>>>=20 >>>> Only for confidential clients. No authentication is required for publi= c >>>> clients. >>>>=20 >>>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) = >>>> wrote: >>>>>=20 >>>>> Except a refresh token is not purely bearer. The client is required to= >>>>> authenticate to use it. >>>>>=20 >>>>> Phil >>>>>=20 >>>>>> On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >>>>>>=20 >>>>>> I'd be curious to the response to this too. >>>>>>=20 >>>>>> Seems to me that refresh token has the same possible security risks i= n >>>>>> an Angular app as an access token, except the refresh token is valid >>>>>> longer....Still, if you did the implicit flow, you'd have to have >>>>>> longer access token timeouts as it would be really annoying for the >>>>>> user to have to login again and again in a long session with your >>>>>> Angular app. >>>>>>=20 >>>>>> We have a javascript adapter that does Authz Code Flow with PKCE for >>>>>> our Angular app. It also does CORS checks on the code to token XHR >>>>>> request just in case on the IDP side. >>>>>>=20 >>>>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer >>>>>>> wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> there were some discussions in January regarding recommendations for= >>>>>>> browser-based apps >>>>>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).= >>>>>>>=20 >>>>>>> I'd just like to ask if the Authorization Code Flow with PKCE is a >>>>>>> valid >>>>>>> option for Single-Page-Applications (in our case Angular), because >>>>>>> Implicit >>>>>>> Flow cannot be used in our scenario. >>>>>>>=20 >>>>>>> Authorization Code Flow with PKCE eliminates the necessity for clien= t >>>>>>> secrets, but our concern is that exposing the refresh token to the S= PA >>>>>>> might >>>>>>> be a security risk, compared to the Implicit Flow were no refresh to= ken >>>>>>> is >>>>>>> exposed. >>>>>>>=20 >>>>>>> What's your take on this? >>>>>>>=20 >>>>>>> Kind regards, >>>>>>> Stefan B=C3=BCringer >>>>>>>=20 >>>>>>> P.S. I couldn't find that much on the internet regarding Authorizati= on >>>>>>> Code >>>>>>> Flow with PKCE in SPAs, if you have some recommendations for good bl= og >>>>>>> posts >>>>>>> I would be grateful. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Bill Burke >>>>>> Red Hat >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Bill Burke >>> Red Hat >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1AFBC675-E2C8-4178-99EC-DC56015D29CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
While we did see android support in Ja= nuary 2017, Chrome and Opera only offered support a few months ago. FireFox h= as a bug on this with notes suggesting it will be rolled out in a year or so= . And while the original RFC expired, it's being rolled into the cookie RFC p= er my understanding.

I also asked the author of thi= s standard for additional commentary, I'll get back to you.

--
Jim Manico
@Manicode

On Se= p 20, 2017, at 1:21 PM, Neil Madden <neil.madden@forgerock.com> wrote:

Is this growing in support? It seems like a g= ood idea, but when I reviewed it recently the draft had expired almost a yea= r ago and still only Chrome and Opera had implemented it. =46rom the outside= it looks as if it has (inexplicably) died. Do you know if there is some act= ivity happening behind the scenes?

-- Neil

On 20 Sep 2017, at 02:31, Jim Manico <jim@manicode.com> wrote:

Not always, Bill. There is a new standard called "same site cookies= " or "first party cookies" that allows you to programmatically remove this r= isk in some modern browsers, it's worth reviewing. 
It's live in Chrome and Opera and will only grow in support. http://caniuse.com/#search=3Dsamesit= e

Jim


<= div>
On Sep 20, 2017, at 8:44 AM, Bill Burke <bburke@redhat.com> wrote:

Cookies are vulnerable to CXRF.

On Tue, Sep 19, 2017 at 7:48 PM, nov matake <matake@gmail.com> wrote:
Why not using http-only cookies instead of refresh tokens?<= /span>
If the app can intera= ct with AuthZ server through a hidden iframe with
prompt=3Dnone param, you shouldn=E2=80=99t need= refresh tokens.

If your SAP is running o= n a different domain with the backend server,
Safari=E2=80=99s Intelligent Tracking Prevention wi= ll break the hidden iframe way
though.

On Sep 20, 2017, at 7:3= 2, John Bradley <ve7jtb@ve7jtb.com> wrote:
=
Right,  Refresh token i= s bearer for native apps, that is why we came up with
PKCE to protect code.

For Angular the code flow with PKCE is probably better than the= token
response type.=

However with bearer tokens it is still r= iskier than code with a confidential
client so the AS should take that into account and not allow= refresh tokens
to li= ve forever.
One future way to protect ref= resh tokens and perhaps Access tokens is to use
token binding to bind the tokens to the user agen= t.   You could do that now
for refresh tokens in Edge (Chrome has TB off by default sti= ll).

I think more work needs to be done t= o come up with a best practice for SPA.

J= ohn B.

On Sep 19, 2017, at 7:02 PM, Adam L= ewis <adam.lewis@moto= rolasolutions.com>
<= span>wrote:
Only for confidential clients= .  No authentication is required for public
clients.

On T= ue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.hunt@oracle.com>
wrote:

Except a refresh token i= s not purely bearer. The client is required to
authenticat= e to use it.
<= blockquote type=3D"cite">
Phil

On Sep 19, 2017, at 2:33 PM, Bill B= urke <bburke@redhat.com> wrot= e:

I'd be curious to the response to t= his too.

=
Seems to me that refresh toke= n has the same possible security risks in
an Angular app as an access token, except the refresh= token is valid
lon= ger....Still, if you did the implicit flow, you'd have to have
longer access token timeouts as i= t would be really annoying for the
user to have to login again and again in a long session with= your
Angular app.<= /span>
<= blockquote type=3D"cite">

We have a javascript adapter that doe= s Authz Code Flow with PKCE for
our Angular app.  It also does CORS checks on the code to t= oken XHR
request jus= t in case on the IDP side.
=

On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer <sbueringer@gmail.com>
=
wrote:
Hi,
<= /blockquote>

there were some discussions in January regarding recommendations for
browser-based apps
(https://www.ietf.org/= mail-archive/web/oauth/current/msg16874.html).

I'd just like to ask if the Authorization Code Flow with PKCE i= s a
valid
option for Single-Page-App= lications (in our case Angular), because
Implicit=
Flow cannot be used in our scenario.

Authorization Code Flow with PKCE eliminates the necessity for c= lient
secrets, but our concern is that exposing the refr= esh token to the SPA
might
be a securi= ty risk, compared to the Implicit Flow were no refresh token
<= span>is
exposed.
<= blockquote type=3D"cite">

What's your take on this?

Kind re= gards,
Stefan B=C3=BCringer
<= br>
P.S. I couldn't find that much on the internet regarding Author= ization
Code
Flow with PKCE in SPAs,= if you have some recommendations for good blog
posts
I would be grateful.
<= /blockquote>

_______________________________________________
<= /blockquote>
OAuth= mailing list
=
OAuth@ie= tf.org
<= blockquote type=3D"cite">https://www.ietf.org/mailman/listinfo/oauth




<= /blockquote>
--
Bill Burke
Red H= at

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

<= blockquote type=3D"cite">_____________________________________________= __
OAuth mailing list
=
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=


___________________________________________= ____
OAuth mailing li= st
OAuth@ietf.org
https:/= /www.ietf.org/mailman/listinfo/oauth

<= /span>
_____________________= __________________________
= 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




--
Bill= Burke
Red Hat

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf= .org/mailman/listinfo/oauth
___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth
= --Apple-Mail-1AFBC675-E2C8-4178-99EC-DC56015D29CB-- From nobody Wed Sep 20 00:22:37 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151A513307B for ; Wed, 20 Sep 2017 00:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 N4GYljeWh6pw for ; Wed, 20 Sep 2017 00:22:33 -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 54A28132025 for ; Wed, 20 Sep 2017 00:22:33 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id x78so1121119pff.10 for ; Wed, 20 Sep 2017 00:22:33 -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=hJwkOcEzMC3TlANBENJQVN1ZZqe5RPPXN6HApiOUgIs=; b=sh8n9udYPSIPBcc3qNqMNiEpLpZKiQtI11CBe1ZlM+Lv91aLzoDA1C40UgKYGEweBa Ar8OidoEkQ5fFJBGc0U//YIZRGk/dbPLZqinwGW3hfYo6HXwXseZ56Wq3tuRiHKdj1+C crmJ6jtCPAaEirY1lv/H/B0fYvc1k3lIBvN0tLCpxIJr73ZGkk/wARTQvTUmlj9YznGh 6ITSaejQC/SgVXzcVg+3I8Y+bjAKsa6bALrhuxSui+HebEolvgFJKR9QxQ4s7AuJpXUa pKe14H0GLChUB9C/YjJsOKvRJ76u81jpcXpaEnYabWJqA4MFJomdsEx4un6GYW545xkK l8rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hJwkOcEzMC3TlANBENJQVN1ZZqe5RPPXN6HApiOUgIs=; b=NJqkkt2TYH/wyRSmztckk0KtS3hMqlcy6Q/lSSK+A5Y1LtPQopckLMtS6BDmaG9FzT hiF1cLjDW23xLHkbFAHcSJE2002X86Akem8wQwoXbHBi7hdfDE54queVscWdlUaZFco8 TzSJweEuU2UeLIawLZt3q9u5RPafFqoSn5pjmVTUgxaCq2q1Atkm+g1adrNdZzHznstm NeGbp16wNyh4QGNZRgnjMEMVt2fuW9MeHgQEYIq5DUvodMJ2rvUlGwhmA3zXznHtdp3R ITcRVBSilBpiEiZRbPqxllqPXBBx1WWP7ex3uPZRQ+16/v7OIS290nSkqI38XQWWTg4V Decg== X-Gm-Message-State: AHPjjUi/1J0onvaXCPCgExoafJo+pTFsCeYK8iRDuHkIt1axPY0YgzeM BF3O2PNO6BUsQQMvnnpRbSSTuxdPd+M= X-Google-Smtp-Source: AOwi7QBm6ywB2oqnR69/iixegmzvhX0tCPM47SBBEbS7ON+6UlWdFLxA37AOxHRCmVg68GhlkvF0Hg== X-Received: by 10.84.160.204 with SMTP id v12mr1173210plg.382.1505892152370; Wed, 20 Sep 2017 00:22:32 -0700 (PDT) Received: from [172.19.248.94] ([104.153.224.167]) by smtp.gmail.com with ESMTPSA id s62sm6361260pfe.91.2017.09.20.00.22.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 00:22:31 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B7029988-AF8C-4907-BBA0-503920696552 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14G60) In-Reply-To: <555F5261-7F4B-4BFD-8911-A8BFD675EE3F@forgerock.com> Date: Wed, 20 Sep 2017 15:22:21 +0800 Cc: Bill Burke , OAuth WG Content-Transfer-Encoding: 7bit Message-Id: References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> <1A823C26-FC05-48C1-A2E1-7B2B6A2607BB@manicode.com> <555F5261-7F4B-4BFD-8911-A8BFD675EE3F@forgerock.com> To: Neil Madden Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 07:22:36 -0000 --Apple-Mail-B7029988-AF8C-4907-BBA0-503920696552 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable PS: The RFC for SameSite cookies has moved to here. https://tools.ietf.org/h= tml/draft-ietf-httpbis-rfc6265bis It's an approved standard and was rolled into the new cookie RFC. Chrome support has a big impact on mobile and elsewhere. But I agree we need= to see FireFox and Safari support and expect to see it within a year. But that should not stop folks from using it today. It's backwards compatibl= e with existing cookie behavior and is quite beautiful in it's simplicity and power to defend against CSRF. Aloha, Jim > On Sep 20, 2017, at 1:21 PM, Neil Madden wrote= : >=20 > Is this growing in support? It seems like a good idea, but when I reviewed= it recently the draft had expired almost a year ago and still only Chrome a= nd Opera had implemented it. =46rom the outside it looks as if it has (inexp= licably) died. Do you know if there is some activity happening behind the sc= enes? >=20 > -- Neil >=20 >> On 20 Sep 2017, at 02:31, Jim Manico wrote: >>=20 >> Not always, Bill. There is a new standard called "same site cookies" or "= first party cookies" that allows you to programmatically remove this risk in= some modern browsers, it's worth reviewing.=20 >>=20 >> https://tools.ietf.org/html/draft-west-first-party-cookies-07 >>=20 >> It's live in Chrome and Opera and will only grow in support. http://caniu= se.com/#search=3Dsamesite >>=20 >> Jim >>=20 >>=20 >>> On Sep 20, 2017, at 8:44 AM, Bill Burke wrote: >>>=20 >>> Cookies are vulnerable to CXRF. >>>=20 >>>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: >>>> Why not using http-only cookies instead of refresh tokens? >>>> If the app can interact with AuthZ server through a hidden iframe with >>>> prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. >>>>=20 >>>> If your SAP is running on a different domain with the backend server, >>>> Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden i= frame way >>>> though. >>>>=20 >>>> On Sep 20, 2017, at 7:32, John Bradley wrote: >>>>=20 >>>> Right, Refresh token is bearer for native apps, that is why we came up= with >>>> PKCE to protect code. >>>>=20 >>>> For Angular the code flow with PKCE is probably better than the token >>>> response type. >>>>=20 >>>> However with bearer tokens it is still riskier than code with a confide= ntial >>>> client so the AS should take that into account and not allow refresh to= kens >>>> to live forever. >>>>=20 >>>> One future way to protect refresh tokens and perhaps Access tokens is t= o use >>>> token binding to bind the tokens to the user agent. You could do that= now >>>> for refresh tokens in Edge (Chrome has TB off by default still). >>>>=20 >>>> I think more work needs to be done to come up with a best practice for S= PA. >>>>=20 >>>> John B. >>>>=20 >>>> On Sep 19, 2017, at 7:02 PM, Adam Lewis >>>> wrote: >>>>=20 >>>> Only for confidential clients. No authentication is required for publi= c >>>> clients. >>>>=20 >>>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) = >>>> wrote: >>>>>=20 >>>>> Except a refresh token is not purely bearer. The client is required to= >>>>> authenticate to use it. >>>>>=20 >>>>> Phil >>>>>=20 >>>>>> On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >>>>>>=20 >>>>>> I'd be curious to the response to this too. >>>>>>=20 >>>>>> Seems to me that refresh token has the same possible security risks i= n >>>>>> an Angular app as an access token, except the refresh token is valid >>>>>> longer....Still, if you did the implicit flow, you'd have to have >>>>>> longer access token timeouts as it would be really annoying for the >>>>>> user to have to login again and again in a long session with your >>>>>> Angular app. >>>>>>=20 >>>>>> We have a javascript adapter that does Authz Code Flow with PKCE for >>>>>> our Angular app. It also does CORS checks on the code to token XHR >>>>>> request just in case on the IDP side. >>>>>>=20 >>>>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer >>>>>>> wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> there were some discussions in January regarding recommendations for= >>>>>>> browser-based apps >>>>>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).= >>>>>>>=20 >>>>>>> I'd just like to ask if the Authorization Code Flow with PKCE is a >>>>>>> valid >>>>>>> option for Single-Page-Applications (in our case Angular), because >>>>>>> Implicit >>>>>>> Flow cannot be used in our scenario. >>>>>>>=20 >>>>>>> Authorization Code Flow with PKCE eliminates the necessity for clien= t >>>>>>> secrets, but our concern is that exposing the refresh token to the S= PA >>>>>>> might >>>>>>> be a security risk, compared to the Implicit Flow were no refresh to= ken >>>>>>> is >>>>>>> exposed. >>>>>>>=20 >>>>>>> What's your take on this? >>>>>>>=20 >>>>>>> Kind regards, >>>>>>> Stefan B=C3=BCringer >>>>>>>=20 >>>>>>> P.S. I couldn't find that much on the internet regarding Authorizati= on >>>>>>> Code >>>>>>> Flow with PKCE in SPAs, if you have some recommendations for good bl= og >>>>>>> posts >>>>>>> I would be grateful. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Bill Burke >>>>>> Red Hat >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Bill Burke >>> Red Hat >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-B7029988-AF8C-4907-BBA0-503920696552 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
PS: The RFC for SameSite cookies has m= oved to here. https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis

= It's an approved standard and was rolled into the new cookie RFC.

Chrome sup= port has a big impact on mobile and elsewhere. But I agree we need to see Fi= reFox and Safari support and expect to see it within a year.

But that shoul= d not stop folks from using it today. It's backwards compatible with existin= g cookie behavior and is quite beautiful in it's
simplicity and power to defend against CSRF.

Aloha,
Jim

On Sep 20, 2= 017, at 1:21 PM, Neil Madden <neil.madden@forgerock.com> wrote:

Is this growing in support? It seems like a good idea= , but when I reviewed it recently the draft had expired almost a year ago an= d still only Chrome and Opera had implemented it. =46rom the outside it look= s as if it has (inexplicably) died. Do you know if there is some activity ha= ppening behind the scenes?

-- Neil

On= 20 Sep 2017, at 02:31, Jim Manico <j= im@manicode.com> wrote:

<= meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8">Not always, Bill. There is a new standard called "same site cookies" or "fi= rst party cookies" that allows you to programmatically remove this risk in s= ome modern browsers, it's worth reviewing. 

http= s://tools.ietf.org/html/draft-west-first-party-cookies-07

=
It's li= ve in Chrome and Opera and will only grow in support. http://caniuse.com/#search=3Dsamesite

Jim


On Sep 20, 2017, at 8:44 AM, Bill Burke <bburke@redhat.com> wrote:

Cookies are vulnerable to CXRF.

On Tue, Sep 19, 2017 at 7:48 PM, nov matake <matake@gmail.com> wrote:
Why not using http-only cookies instead of refresh tokens?<= br>
If the app can interact with= AuthZ server through a hidden iframe with
prompt=3Dnone param, you shouldn=E2=80=99t need refres= h tokens.

=
If your SAP is running on a dif= ferent domain with the backend server,
Safari=E2=80=99s Intelligent Tracking Prevention will brea= k the hidden iframe way
though.
On Sep 20, 2017, at 7:32, John= Bradley <ve7jtb@ve7jtb.com> w= rote:

Right,  Refresh token is beare= r for native apps, that is why we came up with
PKCE to protect code.

For Angular the code flow with PKCE is probably better than the token=
response type.

However with bearer tokens it is still riskier= than code with a confidential
client so the AS should take that into account and not allow refre= sh tokens
to live for= ever.

One future way to protect refresh t= okens and perhaps Access tokens is to use
token binding to bind the tokens to the user agent. &nb= sp; You could do that now
for refresh tokens in Edge (Chrome has TB off by default still).

I think more work needs to be done to come= up with a best practice for SPA.

John B.=

On Sep 19, 2017, at 7:02 PM, Adam Lewis &= lt;adam.lewis@motorolaso= lutions.com>
w= rote:

Only for confidential clients. &nbs= p;No authentication is required for public
clients.

On Tue, Se= p 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.hunt@oracle.com>
wrote:

Except a refresh token is not pu= rely bearer. The client is required to
<= blockquote type=3D"cite">
authenticate to use= it.

Phil

=
On Sep 19, 2017, at 2:33 PM, Bill Burke &l= t;bburke@redhat.com> wrote:

I'd be curious to the response to this to= o.

Seems to me that refresh token has= the same possible security risks in
an Angular app as an access token, except the refresh toke= n is valid
longer..= ..Still, if you did the implicit flow, you'd have to have
longer access token timeouts as it wo= uld be really annoying for the
user to have to login again and again in a long session with you= r
Angular app.

We have a javascript adapter that does Au= thz Code Flow with PKCE for
our Angular app.  It also does CORS checks on the code to toke= n XHR
request just i= n case on the IDP side.
<= span>
On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer <sbueringer@gmail.com>
=
wrote:
Hi,
<= /blockquote>

there were some discussions in January regarding recommendations for
browser-based apps
(https://www.ietf.org/= mail-archive/web/oauth/current/msg16874.html).

I'd just like to ask if the Authorization Code Flow with PKCE i= s a
valid
option for Single-Page-App= lications (in our case Angular), because
Implicit=
Flow cannot be used in our scenario.

Authorization Code Flow with PKCE eliminates the necessity for c= lient
secrets, but our concern is that exposing the refr= esh token to the SPA
might
be a securi= ty risk, compared to the Implicit Flow were no refresh token
<= span>is
exposed.
<= blockquote type=3D"cite">

What's your take on this?

Kind re= gards,
Stefan B=C3=BCringer
<= br>
P.S. I couldn't find that much on the internet regarding Author= ization
Code
Flow with PKCE in SPAs,= if you have some recommendations for good blog
posts
I would be grateful.
<= /blockquote>

_______________________________________________
<= /blockquote>
OAuth= mailing list
=
OAuth@ie= tf.org
<= blockquote type=3D"cite">https://www.ietf.org/mailman/listinfo/oauth




<= /blockquote>
--
Bill Burke
Red H= at

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

<= blockquote type=3D"cite">_____________________________________________= __
OAuth mailing list
=
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=


___________________________________________= ____
OAuth mailing li= st
OAuth@ietf.org
https:/= /www.ietf.org/mailman/listinfo/oauth

<= /span>
_____________________= __________________________
= 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




--
Bill= Burke
Red Hat

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf= .org/mailman/listinfo/oauth
___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth
= --Apple-Mail-B7029988-AF8C-4907-BBA0-503920696552-- From nobody Thu Sep 21 14:06:16 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551BA132F2E for ; Thu, 21 Sep 2017 14:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 b1mSicbmNXTG for ; Thu, 21 Sep 2017 14:06:10 -0700 (PDT) Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF85133044 for ; Thu, 21 Sep 2017 14:06:10 -0700 (PDT) Received: by mail-ua0-f174.google.com with SMTP id k23so4391627uaf.4 for ; Thu, 21 Sep 2017 14:06:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JuGMtLGFUOIaryPsRCVOSfeOfbB9lRpG3GXwF+eI+xM=; b=SCwJ9x9De+T3+HzB8f3BRXoCA13F+9pJYmOpBfEU34rrqhULWVDsk7S2f/6cHA2szF 1RMD3wRHJKPDCyap4zhLuLMexxHhseRO2qKsslDS+rKvB7BR96Eq9D1SND064l/mQDN8 SS6BO4O/EUEBL9cMQuVPp84Q7MME9ENA9DLqAdB69fnOG0F0Ue1LpaOcgPN47iXtt2Vh ErQEqnHBGYWuuIlGgeT2HnA9cWWYxKDB9deEdG/IqOswcOmcc57b0L06mAqqiIbs9UQn /rpBPyzyUIG2SEPPRUgiptpn3D8Nk3bYgH9gObW23exSOjc5t3llqvxqsV9VI0HFJ3Bb AHfg== X-Gm-Message-State: AHPjjUhoQoV/GdHJpjpusWq1a/LVrBEP/gTDV9tOb4YQ/WTLw0SzvZNY cp76CmCVgKcQpwLauLGEdPSE6aE6in6vUJoxe/HwGw== X-Google-Smtp-Source: AOwi7QBA/TeKVvadGNVXktqmScmqpukywjtwAaT1kdOP3uHJpMJl2cFdjxlO89zwoicfDs5L7rvRyTw9m03QyPKpqN4= X-Received: by 10.176.19.231 with SMTP id n36mr3100877uae.68.1506027968921; Thu, 21 Sep 2017 14:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.55.79 with HTTP; Thu, 21 Sep 2017 14:06:08 -0700 (PDT) In-Reply-To: References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> <1A823C26-FC05-48C1-A2E1-7B2B6A2607BB@manicode.com> <555F5261-7F4B-4BFD-8911-A8BFD675EE3F@forgerock.com> From: Bill Burke Date: Thu, 21 Sep 2017 17:06:08 -0400 Message-ID: To: Jim Manico Cc: Neil Madden , OAuth WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 21:06:13 -0000 Back to the OP...Why would browser Javascript implementing Authz Code flow with public client be vulnerable? Not understanding how an XSS attack could work in such a scenario. On Wed, Sep 20, 2017 at 3:22 AM, Jim Manico wrote: > PS: The RFC for SameSite cookies has moved to here. > https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis > > It's an approved standard and was rolled into the new cookie RFC. > > Chrome support has a big impact on mobile and elsewhere. But I agree we n= eed > to see FireFox and Safari support and expect to see it within a year. > > But that should not stop folks from using it today. It's backwards > compatible with existing cookie behavior and is quite beautiful in it's > simplicity and power to defend against CSRF. > > Aloha, > Jim > > On Sep 20, 2017, at 1:21 PM, Neil Madden wrot= e: > > Is this growing in support? It seems like a good idea, but when I reviewe= d > it recently the draft had expired almost a year ago and still only Chrome > and Opera had implemented it. From the outside it looks as if it has > (inexplicably) died. Do you know if there is some activity happening behi= nd > the scenes? > > -- Neil > > On 20 Sep 2017, at 02:31, Jim Manico wrote: > > Not always, Bill. There is a new standard called "same site cookies" or > "first party cookies" that allows you to programmatically remove this ris= k > in some modern browsers, it's worth reviewing. > > https://tools.ietf.org/html/draft-west-first-party-cookies-07 > > It's live in Chrome and Opera and will only grow in support. > http://caniuse.com/#search=3Dsamesite > > Jim > > > On Sep 20, 2017, at 8:44 AM, Bill Burke wrote: > > Cookies are vulnerable to CXRF. > > On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: > > Why not using http-only cookies instead of refresh tokens? > > If the app can interact with AuthZ server through a hidden iframe with > > prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. > > > If your SAP is running on a different domain with the backend server, > > Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden if= rame way > > though. > > > On Sep 20, 2017, at 7:32, John Bradley wrote: > > > Right, Refresh token is bearer for native apps, that is why we came up w= ith > > PKCE to protect code. > > > For Angular the code flow with PKCE is probably better than the token > > response type. > > > However with bearer tokens it is still riskier than code with a confident= ial > > client so the AS should take that into account and not allow refresh toke= ns > > to live forever. > > > One future way to protect refresh tokens and perhaps Access tokens is to = use > > token binding to bind the tokens to the user agent. You could do that n= ow > > for refresh tokens in Edge (Chrome has TB off by default still). > > > I think more work needs to be done to come up with a best practice for SP= A. > > > John B. > > > On Sep 19, 2017, at 7:02 PM, Adam Lewis > > wrote: > > > Only for confidential clients. No authentication is required for public > > clients. > > > On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) > > wrote: > > > Except a refresh token is not purely bearer. The client is required to > > authenticate to use it. > > > Phil > > > On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: > > > I'd be curious to the response to this too. > > > Seems to me that refresh token has the same possible security risks in > > an Angular app as an access token, except the refresh token is valid > > longer....Still, if you did the implicit flow, you'd have to have > > longer access token timeouts as it would be really annoying for the > > user to have to login again and again in a long session with your > > Angular app. > > > We have a javascript adapter that does Authz Code Flow with PKCE for > > our Angular app. It also does CORS checks on the code to token XHR > > request just in case on the IDP side. > > > On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer > > wrote: > > Hi, > > > there were some discussions in January regarding recommendations for > > browser-based apps > > (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). > > > I'd just like to ask if the Authorization Code Flow with PKCE is a > > valid > > option for Single-Page-Applications (in our case Angular), because > > Implicit > > Flow cannot be used in our scenario. > > > Authorization Code Flow with PKCE eliminates the necessity for client > > secrets, but our concern is that exposing the refresh token to the SPA > > might > > be a security risk, compared to the Implicit Flow were no refresh token > > is > > exposed. > > > What's your take on this? > > > Kind regards, > > Stefan B=C3=BCringer > > > P.S. I couldn't find that much on the internet regarding Authorization > > Code > > Flow with PKCE in SPAs, if you have some recommendations for good blog > > posts > > I would be grateful. > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Bill Burke > > Red Hat > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Bill Burke > Red Hat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Bill Burke Red Hat From nobody Sat Sep 23 12:59:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACD61323B4 for ; Sat, 23 Sep 2017 12:59:16 -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=rtfm-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 HysPdla5CuTG for ; Sat, 23 Sep 2017 12:59:13 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3851320D9 for ; Sat, 23 Sep 2017 12:59:13 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id v72so2631395ywa.3 for ; Sat, 23 Sep 2017 12:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xj0EYZQylnpGcUcNATwTj76cUg/BgvWBwMqMeil/fws=; b=QgExB27JZP707aI23G0Y14L8X2B/F3oljMgqg8dHcb1YCE6Mx/2bjHUFAGug/tioV+ F3y9biAfVwdWAIMWR7nca2cUU24VGK7rk/9ABMhVkO+ElUXWZWLg5vX2ZuF3nPWU0+ff 0wvrnUYSCa7Wuwevumv3AxKKEAfpSeeEbBwh7qKXQ0BUGb6Ubt7otdoYVoPPRR8A/8/b Micsxrt0o3aNZkj87we0FEii1VND7+ypX27I1p/lOSP3uPjRqb4CVn+zwFKBitajUygn NTcrh0e7MgjAeBLckk8CA8hlPJy1jGr7cVNvkRlZVFYiDHfqyVk8gUPTcIqrRdc1DEmw WBgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xj0EYZQylnpGcUcNATwTj76cUg/BgvWBwMqMeil/fws=; b=VyLBiq6H9iMNVOqmjwM6zlMFKAPlH8nPcMUFbKDrwrOLDS/3gBu1DSBGDT+HjUQesq 6ChfpFNiDM/erHT0H21DKg2272a/uMuyshd/TIs+0+eEOooBa2nBVmf4RXsK/K8VQg0b MFy874gnE1iNrdYXbywDdKw9VhwZsigltI6xmX+oDgiETVRTUCzrwVR96DNEPpBWuHjz 2lgEo0peq/3gsDqFBt40Zs/O5ku+CXdLzwQ/JcKKMLLdbCEmuPjxqxt0wbAO4c6TqSdG 57eAWtHQ3tAHkXgizauRFifseTt5eEHymEh/MaN58Ay7OvRsg7F7HzzF3C6spQdd1N/d qDzw== X-Gm-Message-State: AHPjjUjcQCPf9lezr24Ng1gMh9Ijqfifjwl0iDoyCIjFs2Bm1EYNcvc5 EWzaSo0lb6KIyx8r9vGHjnisOvah/rt83c7gdUJd/Q== X-Google-Smtp-Source: AOwi7QDm2nBUJOxDX56yLw/mSfJflqcEcaxtq1p3Z+cRhRY0sukDzGD0EUVhRCJymo0bLydOS+c9kU4oA1faw4TZIRI= X-Received: by 10.37.132.73 with SMTP id r9mr1836291ybm.165.1506196752598; Sat, 23 Sep 2017 12:59:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.17 with HTTP; Sat, 23 Sep 2017 12:58:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 23 Sep 2017 12:58:32 -0700 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="089e0826fee4669ea40559e0c26c" Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 19:59:16 -0000 --089e0826fee4669ea40559e0c26c Content-Type: text/plain; charset="UTF-8" Hi Mike, These changes look good. I have pushed the last call button. -Ekr On Mon, Sep 11, 2017 at 12:35 PM, Mike Jones wrote: > Eric, I believe that https://tools.ietf.org/html/ > draft-ietf-oauth-discovery-07 addresses all your comments. Thanks for > them again. > > If you agree, can you please progress the document to the next step? > > Thanks, > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > Sent: Thursday, September 7, 2017 2:25 PM > To: Eric Rescorla ; oauth@ietf.org > Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 > > Draft -07 https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 > contains these proposed resolutions. The only change is that in places > where I'd previously proposed to say "If omitted, these authentication > methods cannot be used" I now say "This metadata entry MUST be present if > either of these authentication methods are specified in the > "{token,revocation,introspection}_endpoint_auth_methods_supported" > entry. No default algorithms are implied if this entry is omitted." > > I made the change because saying that they cannot be used isn't actually > correct. This information could always have been communicated out-of-band > to the metadata. > > -- Mike > > -----Original Message----- > From: Mike Jones > Sent: Tuesday, September 5, 2017 4:12 PM > To: 'Eric Rescorla' ; oauth@ietf.org > Subject: RE: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 > > Thanks for your useful review, Eric. Proposed resolutions to all comments > are inline prefixed by "Mike>". > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Eric Rescorla > Sent: Sunday, September 3, 2017 3:26 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06 > > Hi folks, > > Note: the original of this review is on Phabricator at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D7 > > If you want to see comments in context, you can go there. Also, you can > create an account and respond inline if you like. > If you elect to, let me know if you run into problems. > > -Ekr > > > I have marked a number of places where it seems like you either need > defaults or need to indicate what the semantics are if missing > > > This metadata can either be communicated in a self-asserted fashion > or as a set of signed metadata values represented as claims in a JSON I > assume "self-asserted" in this case means "asserted by the server origin > via HTTPS" > > Mike> Thanks - I will use this language. > > Line 222 > authentication methods. Servers SHOULD support "RS256". The > value "none" MUST NOT be used. > What's the default if omitted? > > Mike> I will add "If omitted, these authentication methods cannot be used." > > Line 235 > represented as a JSON array of BCP47 [RFC5646] language tag > values. > What's the default if omitted? > > Mike> There is no default. I will add "If omitted, the set of supported > languages and scripts is unspecified." > > Line 267 > "OAuth Token Endpoint Authentication Methods" registry > [IANA.OAuth.Parameters]. > What's the default if omitted? > > Mike> I will add client_secret_basic as the default - just like it already > was for token_endpoint_auth_methods_supported. > > Line 275 > "client_secret_jwt" authentication methods. The value "none" MUST > NOT be used. > What's the default if omitted? > > Mike> I will add "If omitted, these authentication methods cannot be used." > > Line 288 > Access Token Types" registry [IANA.OAuth.Parameters]. (These > values are and will remain distinct, due to Section 7.2.) What's the > default if omitted? > > Mike> There is no obvious default. Therefore, I will add "If omitted, the > set of supported authentication methods MUST be determined by other means." > > Line 296 > "client_secret_jwt" authentication methods. The value "none" MUST > NOT be used. > What's the default if omitted? > > Mike> I will add "If omitted, these authentication methods cannot be used." > > Line 304 > challenge method values are those registered in the IANA "PKCE > Code Challenge Methods" registry [IANA.OAuth.Parameters]. > What's the default if omitted? > > Mike> I will add "If omitted, the authorization server does not support > PKCE." > > Line 343 > MUST be registered in the IANA "Well-Known URIs" registry > [IANA.well-known]. > IMPORTANT: Shouldn't this be required to be HTTPS > > Mike> I will add "This path MUST use the "https" scheme." > > Line 500 > client MUST perform a TLS/SSL server certificate check, per RFC 6125 > [RFC6125]. Implementation security considerations can be found in > Recommendations for Secure Use of TLS and DTLS [BCP195]. > Hmm.... I'm unsure about whether this should be a citation to 2818. Is the > general feeling that 6125 superceded 2818? > > Mike> OAuth 2.0 [RFC 6749] also requires an RFC 6125 certificate > validation, so this is in line with other uses of the OAuth protocol family. > > Line 564 > The following registration procedure is used for the registry > established by this specification. > This section seems like it needs RFC2119 language > > Mike> This registry language closely follows that in OAuth 2.0 [RFC 6749] > and subsequent OAuth specifications. I'd rather keep them parallel unless > something isn't clear. > > Line 568 > Values are registered on a Specification Required [RFC5226] basis > after a two-week review period on the mailto:oauth-ext-review@ietf.org > mailing list, on the advice of one or more Designated Experts. > What happens if you don't do anything within two weeks. > > As it says later in this section "Registration requests that are > undetermined for a period longer than 21 days can be brought to the IESG's > attention (using the iesg@ietf.org mailing list) for resolution." > > Line 756 > o Change Controller: IESG > o Specification Document(s): Section 2 of [[ this specification ]] > Extra whitespace. > > Are you talking about there being two spaces between the bullet character > "o" and the items such as "Change Controller: IESG"? That's what style='symbols'> does. Or are you wanting more whitespace somewhere? > Please give more context because I'm not looking at this on Phabricator. > (I created an account "mbj" but it wanted me to install a second factor > phone app, which seemed like a bit much...) > > Thanks, > -- Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e0826fee4669ea40559e0c26c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike,

These changes look good. I hav= e pushed the last call button.

-Ekr
=





On Mon, Sep 11, = 2017 at 12:35 PM, Mike Jones <Michael.Jones@microsoft.com>= ; wrote:
Eric, I believe that https://tools.ietf.org/html/draft-ietf-oau= th-discovery-07 addresses all your comments.=C2=A0 Thanks for them agai= n.

If you agree, can you please progress the document to the next step?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Mike Jones
Sent: Thursday, September 7, 2017 2:25 PM
To: Eric Rescorla <ekr@rtfm.com>;= oauth@ietf.org
Subject: Re: [OAUTH-WG] AD Review: draft-ietf= -oauth-discovery-06

Draft -07 https://tools.ietf.org/html/= draft-ietf-oauth-discovery-07 contains these proposed resolutions.=C2= =A0 The only change is that in places where I'd previously proposed to = say "If omitted, these authentication methods cannot be used" I n= ow say "This metadata entry MUST be present if either of these authent= ication methods are specified in the "{token,revocation,introspec= tion}_endpoint_auth_methods_supported" entry.=C2=A0 No default al= gorithms are implied if this entry is omitted."

I made the change because saying that they cannot be used isn't actuall= y correct.=C2=A0 This information could always have been communicated out-o= f-band to the metadata.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: Mike Jones
Sent: Tuesday, September 5, 2017 4:12 PM
To: 'Eric Rescorla' <ekr@rtfm.co= m>; oauth@ietf.org
Subject: RE: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06

Thanks for your useful review, Eric.=C2=A0 Proposed resolutions to all comm= ents are inline prefixed by "Mike>".

From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Eric Rescorla
Sent: Sunday, September 3, 2017 3:26 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06

Hi folks,

Note: the original of this review is on Phabricator at:

=C2=A0 https://mozphab-ietf.devsvcdev.mozaws.net/D7=

If you want to see comments in context, you can go there. Also, you can cre= ate an account and respond inline if you like.
If you elect to, let me know if you run into problems.

-Ekr


I have marked a number of places where it seems like you either need defaul= ts or need to indicate what the semantics are if missing


=C2=A0 =C2=A0This metadata can either be communicated in a self-asserted fa= shion
=C2=A0 =C2=A0or as a set of signed metadata values represented as claims in= a JSON I assume "self-asserted" in this case means "asserte= d by the server origin via HTTPS"

Mike> Thanks - I will use this language.

Line 222
=C2=A0 =C2=A0 =C2=A0 authentication methods.=C2=A0 Servers SHOULD support &= quot;RS256".=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 value "none" MUST NOT be used.
What's the default if omitted?

Mike> I will add "If omitted, these authentication methods cannot b= e used."

Line 235
=C2=A0 =C2=A0 =C2=A0 represented as a JSON array of BCP47 [RFC5646] languag= e tag
=C2=A0 =C2=A0 =C2=A0 values.
What's the default if omitted?

Mike> There is no default.=C2=A0 I will add "If omitted, the set of= supported languages and scripts is unspecified."

Line 267
=C2=A0 =C2=A0 =C2=A0 "OAuth Token Endpoint Authentication Methods"= ; registry
=C2=A0 =C2=A0 =C2=A0 [IANA.OAuth.Parameters].
What's the default if omitted?

Mike> I will add client_secret_basic as the default - just like it alrea= dy was for token_endpoint_auth_methods_supported.

Line 275
=C2=A0 =C2=A0 =C2=A0 "client_secret_jwt" authentication methods.= =C2=A0 The value "none" MUST
=C2=A0 =C2=A0 =C2=A0 NOT be used.
What's the default if omitted?

Mike> I will add "If omitted, these authentication methods cannot b= e used."

Line 288
=C2=A0 =C2=A0 =C2=A0 Access Token Types" registry [IANA.OAuth.Paramete= rs]. =C2=A0(These
=C2=A0 =C2=A0 =C2=A0 values are and will remain distinct, due to Section 7.= 2.) What's the default if omitted?

Mike> There is no obvious default.=C2=A0 Therefore, I will add "If = omitted, the set of supported authentication methods MUST be determined by = other means."

Line 296
=C2=A0 =C2=A0 =C2=A0 "client_secret_jwt" authentication methods.= =C2=A0 The value "none" MUST
=C2=A0 =C2=A0 =C2=A0 NOT be used.
What's the default if omitted?

Mike> I will add "If omitted, these authentication methods cannot b= e used."

Line 304
=C2=A0 =C2=A0 =C2=A0 challenge method values are those registered in the IA= NA "PKCE
=C2=A0 =C2=A0 =C2=A0 Code Challenge Methods" registry [IANA.OAuth.Para= meters].
What's the default if omitted?

Mike> I will add "If omitted, the authorization server does not sup= port PKCE."

Line 343
=C2=A0 =C2=A0MUST be registered in the IANA "Well-Known URIs" reg= istry
=C2=A0 =C2=A0[IANA.well-known].
IMPORTANT: Shouldn't this be required to be HTTPS

Mike> I will add "This path MUST use the "https" scheme.&= quot;

Line 500
=C2=A0 =C2=A0client MUST perform a TLS/SSL server certificate check, per RF= C 6125
=C2=A0 =C2=A0[RFC6125].=C2=A0 Implementation security considerations can be= found in
=C2=A0 =C2=A0Recommendations for Secure Use of TLS and DTLS [BCP195].
Hmm.... I'm unsure about whether this should be a citation to 2818. Is = the general feeling that 6125 superceded 2818?

Mike> OAuth 2.0 [RFC 6749] also requires an RFC 6125 certificate validat= ion, so this is in line with other uses of the OAuth protocol family.

Line 564
=C2=A0 =C2=A0The following registration procedure is used for the registry<= br> =C2=A0 =C2=A0established by this specification.
This section seems like it needs RFC2119 language

Mike> This registry language closely follows that in OAuth 2.0 [RFC 6749= ] and subsequent OAuth specifications.=C2=A0 I'd rather keep them paral= lel unless something isn't clear.

Line 568
=C2=A0 =C2=A0Values are registered on a Specification Required [RFC5226] ba= sis
=C2=A0 =C2=A0after a two-week review period on the mailto:oauth-ext-review@ietf.org
=C2=A0 =C2=A0mailing list, on the advice of one or more Designated Experts.=
What happens if you don't do anything within two weeks.

As it says later in this section "Registration requests that are undet= ermined for a period longer than 21 days can be brought to the IESG's a= ttention (using the iesg@ietf.org mail= ing list) for resolution."

Line 756
=C2=A0 =C2=A0o =C2=A0Change Controller: IESG
=C2=A0 =C2=A0o =C2=A0Specification Document(s): Section 2 of [[ this specif= ication ]] Extra whitespace.

Are you talking about there being two spaces between the bullet character &= quot;o" and the items such as "Change Controller: IESG"?=C2= =A0 That's what <list style=3D'symbols'> does.=C2=A0 Or a= re you wanting more whitespace somewhere?=C2=A0 Please give more context be= cause I'm not looking at this on Phabricator.=C2=A0 (I created an accou= nt "mbj" but it wanted me to install a second factor phone app, w= hich seemed like a bit much...)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--089e0826fee4669ea40559e0c26c-- From nobody Mon Sep 25 09:23:19 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 604B51344C3; Mon, 25 Sep 2017 09:23:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, oauth@ietf.org, draft-ietf-oauth-discovery@ietf.org, Hannes Tschofenig , Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150635659738.27403.3830208740050411888.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 09:23:17 -0700 Archived-At: Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Authorization Server Metadata) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:23:17 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Authorization Server Metadata' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-10-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Sep 27 10:25:55 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1511342EC; Wed, 27 Sep 2017 10:25:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rifaat.ietf@gmail.com, ekr@rtfm.com, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150653315332.25011.10428786780586096514.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 10:25:53 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 17:25:53 -0000 A new meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag core tls ace sipcore acme People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: Please avoid conflict with sec area BoFs. Please avoid Monday. --------------------------------------------------------- From nobody Wed Sep 27 10:31:39 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD306134EA9; Wed, 27 Sep 2017 10:31:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rifaat.ietf@gmail.com, ekr@rtfm.com, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150653349789.24952.11529781356200106104.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 10:31:37 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Update to a Meeting Session Request for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 17:31:38 -0000 An update to a meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag core tls ace sipcore acme fud teep People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: Please avoid conflict with sec area BoFs. Please avoid Monday. --------------------------------------------------------- From nobody Wed Sep 27 10:36:11 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC21134EB2 for ; Wed, 27 Sep 2017 10:36:10 -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 WAkJEp65OdfL for ; Wed, 27 Sep 2017 10:36:07 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E8C134EAE for ; Wed, 27 Sep 2017 10:36:07 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id m103so16297628iod.13 for ; Wed, 27 Sep 2017 10:36:07 -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=RsWw+xvtnkssZ4CzM8D5C7BUH6eh9gDxvczTM8dtc8o=; b=ch7zMY/GR9EeOGNI7EMuF1W3sKulpBT+ISm3OCxYuX1/IoZ6meSMUOz4h/Y4WfjHI6 vr3HwbtIdP+ViD7w/oT46XD/AhQDPCc0uI261ybgWTYh5mCFERszAQsL9cQE0/+ItcAQ 51ht8p8vWeCOVkRzofITzAvY4dPN1pE/oSyMQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RsWw+xvtnkssZ4CzM8D5C7BUH6eh9gDxvczTM8dtc8o=; b=AzTmmUd7j4o1SZA8dAXG3bPG8fW4ZuEM690lVsIoFjYVVHKehUwvlmXvBNMuCRX5Ds MVk6erLLITSCiysUI1lPhjveW758CAoV1E/lLq0EeFBcpKz3hhxxhWBmuU8H1qPo3kA8 9Qo3PkHSr1nfHmAmN7RvK2wA9l1XiKQHndaMZ0UhKav34M8x/LgJU4ty8/GSEwrkd90r GTbwW6Mu/URo/4rMkwZ/XDa83TSGS4NRGoy/AnBwPyjX/FT9siqc5ofIsyL/8ahBK/qD ZWeDzIiboawIN5BrCeh2xWR3jLSigmtn+n3TD1tHbmpyRl6JTpuIQqNdtCAYd8SX0HWw Z+4Q== X-Gm-Message-State: AMCzsaVIwk5SxR7vY0dY4WfFRbtMJekNOgA6E8Wb7FZjLCLg5s7qp+qc XTFh+bzkPr//WvuorJPf3N6GAe6+QmtZ/JRQwxycG6i6qG1zIGm/XHY7TbVSMIeNyXPIdm8Axs/ fQO+cCtOiYYwx6w== X-Google-Smtp-Source: AOwi7QA8D1CxQt9ZoMkDHI0P5J3i8EN58akX8KpDWwHI9F8I5PvmmE/Kejn3IBDNZEx/YZkPAGqne5mXNn85evOYjQc= X-Received: by 10.107.130.224 with SMTP id m93mr3507496ioi.82.1506533766507; Wed, 27 Sep 2017 10:36:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.1.206 with HTTP; Wed, 27 Sep 2017 10:35:35 -0700 (PDT) In-Reply-To: <150653315332.25011.10428786780586096514.idtracker@ietfa.amsl.com> References: <150653315332.25011.10428786780586096514.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 27 Sep 2017 11:35:35 -0600 Message-ID: To: IETF Meeting Session Request Tool Cc: oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113eee7cfef509055a2f3979" Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 17:36:10 -0000 --001a113eee7cfef509055a2f3979 Content-Type: text/plain; charset="UTF-8" Can we possibly also try and avoid conflicts with tokbind? On Wed, Sep 27, 2017 at 11:25 AM, IETF Meeting Session Request Tool < session-request@ietf.org> wrote: > > > A new meeting session request has just been submitted by Rifaat > Shekh-Yusef, a Chair of the oauth working group. > > > --------------------------------------------------------- > Working Group Name: Web Authorization Protocol > Area Name: Security Area > Session Requester: Rifaat Shekh-Yusef > > Number of Sessions: 2 > Length of Session(s): 1.5 Hours, 1.5 Hours > Number of Attendees: 50 > Conflicts to Avoid: > First Priority: saag core tls ace sipcore acme > > > > > People who must be present: > Eric Rescorla > Hannes Tschofenig > Rifaat Shekh-Yusef > > Resources Requested: > > Special Requests: > Please avoid conflict with sec area BoFs. Please avoid Monday. > --------------------------------------------------------- > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a113eee7cfef509055a2f3979 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can we possibly also try and avoid conflicts with tokbind?=

On Wed,= Sep 27, 2017 at 11:25 AM, IETF Meeting Session Request Tool <sessi= on-request@ietf.org> wrote:


A new meeting session request has just been submitted by Rifaat Shekh-Yusef= , a Chair of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef

Number of Sessions: 2
Length of Session(s):=C2=A0 1.5 Hours, 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid:
=C2=A0First Priority: saag core tls ace sipcore acme




People who must be present:
=C2=A0 Eric Rescorla
=C2=A0 Hannes Tschofenig
=C2=A0 Rifaat Shekh-Yusef

Resources Requested:

Special Requests:
=C2=A0 Please avoid conflict with sec area BoFs. Please avoid Monday.
---------------------------------------------------------

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a113eee7cfef509055a2f3979-- From nobody Wed Sep 27 10:40:05 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559DB134EBA; Wed, 27 Sep 2017 10:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 keqmKfXGxSB2; Wed, 27 Sep 2017 10:40:01 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C83A134EB5; Wed, 27 Sep 2017 10:40:01 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id s15so8974765uag.1; Wed, 27 Sep 2017 10:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZnqPc8LB3I+5iZkko31d8DG0JDDPXbQpFhYdLEzuDTc=; b=ZSFuJxC0Bosqb2nB9bBim6A1mYMNtCzxKRpMm8gIZr1w11JWZp8djY5N8879wBnDab vgqI9RoRaoI52O7Kfoz4Jnpv6KZpKItlfpk/aQgOZq3DATiqv/awMRubIoVjAO6+7bYu xWlXOtiISJNyGPIXmn+ZF+vZKHc1FZ1JpG95TrDoX8DXE8EUII4P/OXARWONOii3cESZ 7Bowym54SSNjwZ9t6ObCDyNvGCBn3twf5dvT2mA9Uh8Hxqz04ZBPI/DllGLCQCs857Ik M+X51XY1jesyd9r8ZEdlgYvcbEAPvOs0H+CrrQ4843nZ/bDTbMkz7db/5fZTlnD+SSZY 8HuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZnqPc8LB3I+5iZkko31d8DG0JDDPXbQpFhYdLEzuDTc=; b=ax/r64QqHKMvda2nteb4hmpBBjBG8ILabuuyxgAtVsPjI/NIBYkD2pnkWlxrM6Xf9O lYes25acMykKchdpc1C3BelwGNvWzFBMN4GsdkPkS7HpO3vzi2jR/MaHDSS/2TwOSLBO TWvz6ViuDyc1uVgffBmNAMxiof+cuNLucGFjcIq+Kgm7+Q+AqvBO0mbdivcKs2SlE/Rk tBnJu0s+JeyrwJOKmQm/UutWld4+H8Nr7BSuxYPQolUAdIntw+z7LzxI1HFDbFiB78Cc 84W87xaH9FLsFoK/AEXvLp9hP5I82iwJAgnJAz8gY/ZdNmxBrWERn7fEmN4+Xe1dS6yY Zy3w== X-Gm-Message-State: AHPjjUhW+lELRD5joKeXFviEL7yfakEcQMZbK3lLMKJk/Rmu/+4OYY21 c3XB5cwSfH0ip+FYH0tyeCisIhEPnDcq063yR0o= X-Google-Smtp-Source: AOwi7QBfpRejzGwcUbgmyRYs79IrrrKJ5QH2tnV05GZPRC5FoRc5skznB65A3qPn25mzo5nFSDEBhx5B4ph5/SxhlU0= X-Received: by 10.176.0.172 with SMTP id 41mr1320341uaj.0.1506534000334; Wed, 27 Sep 2017 10:40:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.152 with HTTP; Wed, 27 Sep 2017 10:39:59 -0700 (PDT) In-Reply-To: References: <150653315332.25011.10428786780586096514.idtracker@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Wed, 27 Sep 2017 13:39:59 -0400 Message-ID: To: Brian Campbell Cc: IETF Meeting Session Request Tool , oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113dd5baee9b53055a2f474a" Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 17:40:03 -0000 --001a113dd5baee9b53055a2f474a Content-Type: text/plain; charset="UTF-8" Sure, I will add that to the list. Regards, Rifaat On Wed, Sep 27, 2017 at 1:35 PM, Brian Campbell wrote: > Can we possibly also try and avoid conflicts with tokbind? > > On Wed, Sep 27, 2017 at 11:25 AM, IETF Meeting Session Request Tool < > session-request@ietf.org> wrote: > >> >> >> A new meeting session request has just been submitted by Rifaat >> Shekh-Yusef, a Chair of the oauth working group. >> >> >> --------------------------------------------------------- >> Working Group Name: Web Authorization Protocol >> Area Name: Security Area >> Session Requester: Rifaat Shekh-Yusef >> >> Number of Sessions: 2 >> Length of Session(s): 1.5 Hours, 1.5 Hours >> Number of Attendees: 50 >> Conflicts to Avoid: >> First Priority: saag core tls ace sipcore acme >> >> >> >> >> People who must be present: >> Eric Rescorla >> Hannes Tschofenig >> Rifaat Shekh-Yusef >> >> Resources Requested: >> >> Special Requests: >> Please avoid conflict with sec area BoFs. Please avoid Monday. >> --------------------------------------------------------- >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --001a113dd5baee9b53055a2f474a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, I will add that to the list.

Rega= rds,
=C2=A0Rifaat


On Wed, Sep 27, 2017 at 1:35 PM, Brian= Campbell <bcampbell@pingidentity.com> wrote:
Can we possibly also try and = avoid conflicts with tokbind?

On Wed, Sep 27, 2017 at 11:25 = AM, IETF Meeting Session Request Tool <session-request@ietf.org= > wrote:


A new meeting session request has just been submitted by Rifaat Shekh-Yusef= , a Chair of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef

Number of Sessions: 2
Length of Session(s):=C2=A0 1.5 Hours, 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid:
=C2=A0First Priority: saag core tls ace sipcore acme




People who must be present:
=C2=A0 Eric Rescorla
=C2=A0 Hannes Tschofenig
=C2=A0 Rifaat Shekh-Yusef

Resources Requested:

Special Requests:
=C2=A0 Please avoid conflict with sec area BoFs. Please avoid Monday.
---------------------------------------------------------

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

<= /div> --001a113dd5baee9b53055a2f474a-- From nobody Wed Sep 27 10:40:41 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BB1134ECD; Wed, 27 Sep 2017 10:40:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rifaat.ietf@gmail.com, ekr@rtfm.com, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150653403397.25076.13559497902532244299.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 10:40:33 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Update to a Meeting Session Request for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 17:40:39 -0000 An update to a meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: acme sipcore ace tls core saag fud teep tokbind People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: Please avoid conflict with sec area BoFs. Please avoid Monday. --------------------------------------------------------- From nobody Wed Sep 27 13:11:16 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34723134FDE; Wed, 27 Sep 2017 13:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 RhmDJ5J1UAyu; Wed, 27 Sep 2017 13:11:13 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8917D134FF5; Wed, 27 Sep 2017 13:11:13 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id v3so265385pgv.3; Wed, 27 Sep 2017 13:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z7KNY5/Vh2+uyVKVn/HQMP7SrxgfCt5nzLET+xgnaeE=; b=DNxqP3qAOogJQrMnvHapU9YgoB84ehqoOetSciQDqIJKJViRlVbe7QDsMGSREEwaNI yu/WPKmLcH/XkLer+dmziQU5WDJrP6Qsg+xkdyxHxHEzlnwlLY2nXH4XYa/+N53alVoP kyi/j6h2O9kNZfDx2EIkHuhyhnlhQU8Ykw4RzepOYql5Rm/tW9TDBse7NWEtkG/voNsQ poL455rjpz7BEEB1l6L42f5zfj+m/vfy5a4Hf5Pf17xB6cGJG0Fm5vPSJtsgWOX/Fye6 NXPIcxT2sbb1aE6jKQa8i9/Cu9XdBxhwtyoUui4Pmni6FWeBAEXPozdaj8YZ+eEA40Ev 02Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z7KNY5/Vh2+uyVKVn/HQMP7SrxgfCt5nzLET+xgnaeE=; b=hMmlvBHLVUmAe404GHDPkDr1prlCYigr5v2GdumUC3CaQvKh9RMP6Q53Q4Z+iZmN7E aRKPe2SKk42zh/56GZf/ucDKi2PPF2nZgWe5TdB6A5OaaSpi+FKEuZX2OLRSCwEkW2sS vUVh4EbdDsOkH48XhPZmkrFJn9HoG4rHuUbsWeT8FPXWBshLZyh0Ktrk6ilL6bLjBexb 2ObsZdwCHNleJ2l5K1zIwJWpxrLr9mBBE9bx1g8IOjXwp5JGaarGXWbqLD2t52wHVEIT uHunYZ6TtKq65Qf87/wOHlUtjAyL1TSzDGOzY/GDPwS3BtjFoNwnq+WVV5QtAUDZXOPx R/KA== X-Gm-Message-State: AHPjjUgW8cowlNGaInMls3jlNPoVqygKE+2fCIE5uT9tw3c0c3j6Cmvn v+pFjJuLkpnq9ZgFge9v98hM2VBUEw5esAZfCTY= X-Google-Smtp-Source: AOwi7QB5Bmu5Ts7x98Hvwdub4OMnSE1CsFop0QwV7Iqc3CePw6dP+buS4WtTAa+ikWgEuuSzdO7o5TyHKvHloUkAYq4= X-Received: by 10.99.126.84 with SMTP id o20mr2288738pgn.141.1506543073039; Wed, 27 Sep 2017 13:11:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.150.15 with HTTP; Wed, 27 Sep 2017 13:10:52 -0700 (PDT) In-Reply-To: References: <150653315332.25011.10428786780586096514.idtracker@ietfa.amsl.com> From: Dick Hardt Date: Wed, 27 Sep 2017 13:10:52 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: Brian Campbell , IETF Meeting Session Request Tool , oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b4a7cb519d6055a3164eb" Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:11:15 -0000 --94eb2c1b4a7cb519d6055a3164eb Content-Type: text/plain; charset="UTF-8" And secevent? On Wed, Sep 27, 2017 at 10:39 AM, Rifaat Shekh-Yusef wrote: > Sure, I will add that to the list. > > Regards, > Rifaat > > > On Wed, Sep 27, 2017 at 1:35 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Can we possibly also try and avoid conflicts with tokbind? >> >> On Wed, Sep 27, 2017 at 11:25 AM, IETF Meeting Session Request Tool < >> session-request@ietf.org> wrote: >> >>> >>> >>> A new meeting session request has just been submitted by Rifaat >>> Shekh-Yusef, a Chair of the oauth working group. >>> >>> >>> --------------------------------------------------------- >>> Working Group Name: Web Authorization Protocol >>> Area Name: Security Area >>> Session Requester: Rifaat Shekh-Yusef >>> >>> Number of Sessions: 2 >>> Length of Session(s): 1.5 Hours, 1.5 Hours >>> Number of Attendees: 50 >>> Conflicts to Avoid: >>> First Priority: saag core tls ace sipcore acme >>> >>> >>> >>> >>> People who must be present: >>> Eric Rescorla >>> Hannes Tschofenig >>> Rifaat Shekh-Yusef >>> >>> Resources Requested: >>> >>> Special Requests: >>> Please avoid conflict with sec area BoFs. Please avoid Monday. >>> --------------------------------------------------------- >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* > > > > _______________________________________________ > 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! --94eb2c1b4a7cb519d6055a3164eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And secevent?

On Wed, Sep 27, 2017 at 10:39 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Sure, I will add that to the list.

Regards,
=C2=A0Rifaat


On Wed, Sep 27, 2017 at 1:35 PM, Brian Campbell &= lt;bcampbel= l@pingidentity.com> wrote:
=
Can we possibly also try and avoid conflicts with tokbind?=

On Wed, Sep 27, 2017 at 11:25 AM, IETF= Meeting Session Request Tool <session-request@ietf.org> wrote:


A new meeting session request has just been submitted by Rifaat Shekh-Yusef= , a Chair of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef

Number of Sessions: 2
Length of Session(s):=C2=A0 1.5 Hours, 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid:
=C2=A0First Priority: saag core tls ace sipcore acme




People who must be present:
=C2=A0 Eric Rescorla
=C2=A0 Hannes Tschofenig
=C2=A0 Rifaat Shekh-Yusef

Resources Requested:

Special Requests:
=C2=A0 Please avoid conflict with sec area BoFs. Please avoid Monday.
---------------------------------------------------------

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

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




--
=
Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on!
--94eb2c1b4a7cb519d6055a3164eb-- From nobody Wed Sep 27 13:16:57 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05CF134314; Wed, 27 Sep 2017 13:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 GOt4zURa3ZQI; Wed, 27 Sep 2017 13:16:55 -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 B5E0013247A; Wed, 27 Sep 2017 13:16:54 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id t36so9221657uah.10; Wed, 27 Sep 2017 13:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u62++XQL9Mmm1Ron4YIBrEVSQ36bHPuWKJiYIuZE8WM=; b=YF28rP7NEF204ySi26Amcaa5fvwLm79SbROrGQ2veHLWDKZmHxBHh6RJNw9UqvwElU dmbTI3StR7/iX0zwuwsVWIRBDSWkR0URT+0500WyFNaBVtwT9tm8wZF5VYfeivDFA+Pm mRIiCVOW7CuHZSz/VgnWW/h9qOiBlgAB/Se5vSsUs4F60a60m0vVwvpQmYc+b1SF6/MF x3d05GRyVHjMd+a3IOQjaxOW3hEJWt7EKKcNWGj7Q3h57W7epcDzeb4W5vWyn54TxUb5 mSa1HTj0QLXJPRKAITzJMUaA+XdGYmO4uGT5eRRqK1EqpVWU3/7LGs6x+gfRLwiRDNI0 auGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u62++XQL9Mmm1Ron4YIBrEVSQ36bHPuWKJiYIuZE8WM=; b=RciH+hSID9EptbrmKGLjvPftTr0FL0sICALlTLYaiAh3g936FXrtE5SbQUJUTtbmTp nFcUNKNC5TBj7FYDd9zaoXWx4hy+pDjwDl5FchUu0Ol/QQMm5Wxnrcx9E97wbS2cKgU5 4cozRjsDcAZHShOYJ05ZzzftNfx5O2SWYdC8GwSRO5ijjc9dzJ3cmuMhUicMJNOxqi8s MokiekHHpwSYwJOR2nsattPDHitzeWBcAf8+TMZxc5gGRc21Oa9NLTq4ruKbchrBSsYl fAJv5L+1l2Kt7Z9k9E9t/CZI1zlgWO2gj39j9dMsnSlCuIvTA13Aeg+QB0OlubV1Jgnq S2Xw== X-Gm-Message-State: AHPjjUi4ogeDtIfTXP4EhVkCHwp3pFyBW011iJ6+J+DSGsQvIJXkm+Hz IklYR1k058fUvQjSl+a5hAsw0+WS0oh05Znx9Qo= X-Google-Smtp-Source: AOwi7QAyoQYHQ5/wta8GQMIWbvjhm4WOucacGCdVqiQ5JrjBHb+dHd8nJHAGwBTqSgRU2SZqT+0H6MnHZB6sQTq7T1o= X-Received: by 10.176.0.172 with SMTP id 41mr1587172uaj.0.1506543413860; Wed, 27 Sep 2017 13:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.152 with HTTP; Wed, 27 Sep 2017 13:16:53 -0700 (PDT) In-Reply-To: References: <150653315332.25011.10428786780586096514.idtracker@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Wed, 27 Sep 2017 16:16:53 -0400 Message-ID: To: Dick Hardt Cc: Brian Campbell , IETF Meeting Session Request Tool , oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113dd5ba05a1c4055a31796c" Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:16:56 -0000 --001a113dd5ba05a1c4055a31796c Content-Type: text/plain; charset="UTF-8" Sure On Wed, Sep 27, 2017 at 4:10 PM, Dick Hardt wrote: > And secevent? > > On Wed, Sep 27, 2017 at 10:39 AM, Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> wrote: > >> Sure, I will add that to the list. >> >> Regards, >> Rifaat >> >> >> On Wed, Sep 27, 2017 at 1:35 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> Can we possibly also try and avoid conflicts with tokbind? >>> >>> On Wed, Sep 27, 2017 at 11:25 AM, IETF Meeting Session Request Tool < >>> session-request@ietf.org> wrote: >>> >>>> >>>> >>>> A new meeting session request has just been submitted by Rifaat >>>> Shekh-Yusef, a Chair of the oauth working group. >>>> >>>> >>>> --------------------------------------------------------- >>>> Working Group Name: Web Authorization Protocol >>>> Area Name: Security Area >>>> Session Requester: Rifaat Shekh-Yusef >>>> >>>> Number of Sessions: 2 >>>> Length of Session(s): 1.5 Hours, 1.5 Hours >>>> Number of Attendees: 50 >>>> Conflicts to Avoid: >>>> First Priority: saag core tls ace sipcore acme >>>> >>>> >>>> >>>> >>>> People who must be present: >>>> Eric Rescorla >>>> Hannes Tschofenig >>>> Rifaat Shekh-Yusef >>>> >>>> Resources Requested: >>>> >>>> Special Requests: >>>> Please avoid conflict with sec area BoFs. Please avoid Monday. >>>> --------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited. >>> If you have received this communication in error, please notify the sender >>> immediately by e-mail and delete the message and any file attachments from >>> your computer. Thank you.* >> >> >> >> _______________________________________________ >> 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! > --001a113dd5ba05a1c4055a31796c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure

On Wed, Sep 27, 2017 at 4:10 PM, Dick Hardt <= ;dick.hardt@gmail= .com> wrote:
And secevent?
On Wed, Sep 27, 2017 at 10:39 AM, Rifaat Shekh-= Yusef <rifaat.ietf@gmail.com> wrote:
Sure, I will add that to the list.

=
Regards,
=C2=A0Rifaat


On Wed, Sep 27= , 2017 at 1:35 PM, Brian Campbell <bcampbell@pingidentity.com= > wrote:
Can w= e possibly also try and avoid conflicts with tokbind?

On Wed, Sep 27, 2017 at 11:25 AM, IE= TF Meeting Session Request Tool <session-request@ietf.org> wrote:


A new meeting session request has just been submitted by Rifaat Shekh-Yusef= , a Chair of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef

Number of Sessions: 2
Length of Session(s):=C2=A0 1.5 Hours, 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid:
=C2=A0First Priority: saag core tls ace sipcore acme




People who must be present:
=C2=A0 Eric Rescorla
=C2=A0 Hannes Tschofenig
=C2=A0 Rifaat Shekh-Yusef

Resources Requested:

Special Requests:
=C2=A0 Please avoid conflict with sec area BoFs. Please avoid Monday.
---------------------------------------------------------

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

<= /div>

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




--
Subscribe to the HARDTWARE mail list to lea= rn about projects I am working on!

--001a113dd5ba05a1c4055a31796c-- From nobody Wed Sep 27 13:18:15 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A41D135034; Wed, 27 Sep 2017 13:18:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rifaat.ietf@gmail.com, ekr@rtfm.com, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150654349299.32516.11970117709821175594.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 13:18:12 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Update to a Meeting Session Request for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:18:13 -0000 An update to a meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: teep fud saag core tls ace sipcore acme tokbind secevent People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: Please avoid conflict with sec area BoFs. Please avoid Monday. --------------------------------------------------------- From nobody Fri Sep 29 01:24:38 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78550126BF0 for ; Fri, 29 Sep 2017 01:24:36 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 nFt5SQf0HlqH for ; Fri, 29 Sep 2017 01:24:34 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523BB1243F6 for ; Fri, 29 Sep 2017 01:24:34 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id v13so422660pgq.6 for ; Fri, 29 Sep 2017 01:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=unaIry2HbcJQ1BKrFjXPqXOFJVdfWz0f6foLCz7AlWg=; b=jGPfhVDZDpkjYSty+rEUk9vvCk1cYffuP2hjj/srod7QKGpgQStvqbhQqmahApP85o KUqJIC74SD8VJbdYtcEL63GEvhIBsl9t0FA1ibikK15sEnZfRc9UUE++JwBI8dxxEEg4 pelGTaFzDg7lGd2Ye7NbPrQdiYIDU2IAUgSiBgEkHOBKE43OHbgagd0s1Ul5WMK2KwUd wm4vqoTove9StOw+YOgXJXvYsllaGtN7kMDnXmRkPYsRfPFRUzVN/Zg1ipZpZCkSaNCN eBAiUrzQ4CxuoCh7lYfJK2xYcGU2uvGHLKDtXxTvExBpeddndhh7NQm9wFes5oo4ICvW udCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=unaIry2HbcJQ1BKrFjXPqXOFJVdfWz0f6foLCz7AlWg=; b=V5bJyHPaUbPO3iH4FpXgw3Qu8iocdRQnlYhUnJJbcsu0lk6ImIOA3mIeof3oo4IKd+ cNSzx3oOJSfKGasSzjBnnzggP9n9gmwspXPHmd+TF6Q0h4/4G8byX3h0tZXaYxQLrNZy K9KQVQ0abBtf4m3ys24Y7eqhThNKhMCXSVcVZvCdkaEYLb8cjP0bOEioETGQIYySzCL4 atYyGPq6NpD5qy8N6skjpx3TfyBTaJL7GE4/xHBllFkJtYZ2iataX8jPzY17rvVQKAAb 8ORpffdTQZfZSxO3iHvQzszNAlzTNiUQnSppgbYtqexlTWGh9RIS6/rRIG4sSQpGy4py 8wcw== X-Gm-Message-State: AMCzsaXieefNXfiT2UZ6Jb6l882VSTtfThfCr8UKGCixbXwGsWJmCBf5 Ppb4ED6Zkp7/7O3c7lrCk4BHu1OEpxlWM2ewv0isWA== X-Google-Smtp-Source: AOwi7QB6G5du7PeVFXn7vcopOCpCBTmNNV/31U1IlKZS9zz/hcPQLqkBGGUSRtDi8JKwErXzZvJi4WXXn8Lsp0n+Vtc= X-Received: by 10.101.87.202 with SMTP id q10mr1543128pgr.141.1506673473738; Fri, 29 Sep 2017 01:24:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.170 with HTTP; Fri, 29 Sep 2017 01:24:33 -0700 (PDT) From: Samuel Erdtman Date: Fri, 29 Sep 2017 10:24:33 +0200 Message-ID: To: Hannes Tschofenig , Dick Hardt Cc: "" , Ludwig Seitz Content-Type: multipart/alternative; boundary="089e08237c1831f2bc055a4fc140" Archived-At: Subject: [OAUTH-WG] ACE and OAuth Extensions Error Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 08:24:36 -0000 --089e08237c1831f2bc055a4fc140 Content-Type: text/plain; charset="UTF-8" Hi Hannes and Dick, In the work with the ACE framework ( https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-07) that is based on the OAuth framework I noticed that non of the error response codes described in the OAuth Framework is IANA registered. I could find invalid_request, unauthorized_client, access_denied, unsupported_response_type, invalid_scope, server_error, temporarily_unavailable, invalid_client, invalid_grant by scrolling through the RFC but only a few of them are registered via other RFCs/specifications. Is there a reason for not including these in the IANA registry for OAuth Extensions Error Registry? Is there another registry for these? In the ACE framework we want to map these to integers to save some precious bytes. Thanks //Samuel --089e08237c1831f2bc055a4fc140 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes and Dick,

= In the work with the ACE framework (https://tools.ietf.org/html/draft-ietf-ace-o= auth-authz-07) that is based on the OAuth framework I noticed that non = of the error response codes described in the OAuth Framework is IANA regist= ered.
I could find invalid_request, unauthorized_client, access_denied,= unsupported_response_type, invalid_scope, server_error, temporarily_unavai= lable, invalid_client, invalid_grant by scrolling through the RFC but only = a few of them are registered via other RFCs/specifications.

Is= there a reason for not including these in the IANA registry for OAuth Exte= nsions Error Registry? Is there another registry for these?

In= the ACE framework we want to map these to integers to save some precious b= ytes.

Thanks
//Samuel


=

--089e08237c1831f2bc055a4fc140--