From nobody Sat May 2 03:36:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB2F1A1BE9 for ; Sat, 2 May 2015 03:36:45 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc74kGcspRLF for ; Sat, 2 May 2015 03:36:43 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CFC1A1B5B for ; Sat, 2 May 2015 03:36:43 -0700 (PDT) Received: by widdi4 with SMTP id di4so74769684wid.0 for ; Sat, 02 May 2015 03:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:from:to:mime-version:content-type :content-transfer-encoding; bh=F5E6/SepmU9UbRYWPWbgTfjs64YjV7uocqtBkMvomUM=; b=s2qrFnydjdh/1lluX6fdale21+mlZNoonWgFYieB/Gk95zBRLJpb+jZ2hmolm+YiqT SWxs9ot5Yavg7K5D6P/jnikNyxjGx+gRzbOiIMrxKON76QUQuIKKYqBkXg7wbCjO32LJ SLM2xymDsSUhA3+Oq3MaVSLNriEZsysVo+BD46EdCmvofY0tY4BM86bjrSNckZ5ZSTCF dqJoLDxnBaljZuESiVB0A5QcwEYr8uapbfeCEe+8zTrTc68oRJCHZ+lrysJJQn+qzhsw qL+yZSWzzmFZUdDWQkj09BqG8TzhgLD3MmIvHXpLOF3b4HIh0TDidACtp+mfJCwdR5Bz 8QJg== X-Received: by 10.180.91.137 with SMTP id ce9mr3953080wib.76.1430563001908; Sat, 02 May 2015 03:36:41 -0700 (PDT) Received: from [10.13.205.89] (ip-109-47-194-195.web.vodafone.de. [109.47.194.195]) by mx.google.com with ESMTPSA id fu2sm1819743wic.20.2015.05.02.03.36.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 May 2015 03:36:41 -0700 (PDT) Date: Sat, 02 May 2015 12:31:55 +0200 Message-ID: From: "sooolooo.mm" To: oauth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 78, Issue 31 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 10:36:45 -0000 CgpvYXV0aC1yZXF1ZXN0QGlldGYub3JnIHNjaHJpZWI6Cgo+U2VuZCBPQXV0aCBtYWlsaW5nIGxp c3Qgc3VibWlzc2lvbnMgdG8KPglvYXV0aEBpZXRmLm9yZwo+Cj5UbyBzdWJzY3JpYmUgb3IgdW5z dWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQKPglodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj5vciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2Fn ZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8KPglvYXV0aC1yZXF1ZXN0QGlldGYub3Jn Cj4KPllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdAo+CW9hdXRo LW93bmVyQGlldGYub3JnCj4KPldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVj dCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMKPnRoYW4gIlJlOiBDb250ZW50cyBvZiBPQXV0 aCBkaWdlc3QuLi4iCj4KPgo+VG9kYXkncyBUb3BpY3M6Cj4KPiAgIDEuIEZ3ZDogTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0yMi50eHQ+IChBIHNldAo+ICAgICAgb2Yg U0FTTCBNZWNoYW5pc21zIGZvciBPQXV0aCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQgKEJlbmphbWlu IEthZHVrKQo+Cj4KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+TWVzc2FnZTogMQo+RGF0ZTogVGh1LCAzMCBB cHIgMjAxNSAxNDozNzozNSAtMDQwMCAoRURUKQo+RnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVr QE1JVC5FRFU+Cj5Ubzogb2F1dGhAaWV0Zi5vcmcKPlN1YmplY3Q6IFtPQVVUSC1XR10gRndkOiBM YXN0IENhbGw6Cj4JPGRyYWZ0LWlldGYta2l0dGVuLXNhc2wtb2F1dGgtMjIudHh0PiAoQSBzZXQg b2YgU0FTTCBNZWNoYW5pc21zIGZvcgo+CU9BdXRoKSB0byBQcm9wb3NlZCBTdGFuZGFyZAo+TWVz c2FnZS1JRDogPGFscGluZS5HU08uMS4xMC4xNTA0MzAxNDM0NTUwLjIyMjEwQG11bHRpY3MubWl0 LmVkdT4KPkNvbnRlbnQtVHlwZTogVEVYVC9QTEFJTjsgY2hhcnNldD1VUy1BU0NJSQo+Cj5IaSBh bGwsCj4KPkkganVzdCB3YW50ZWQgdG8gY2FsbCBhdHRlbnRpb24gdG8gdGhpcyBJRVRGIExhc3Qg Q2FsbDsgdGhlcmUgd2VyZSBzb21lCj5jaGFuZ2VzIHNpbmNlIHRoZSAtMTggd2hpY2ggaXMgdGhl IGxhc3Qgb25lIHRoYXQgd2Ugc2VudCB0byB0aGlzIGxpc3QuCj4KPi1CZW4KPgo+LS0tLS0tLS0t LSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tCj5EYXRlOiBUaHUsIDMwIEFwciAyMDE1IDE0 OjMxOjQ3IC0wNDAwCj5Gcm9tOiBUaGUgSUVTRyA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+Cj5S ZXBseS1UbzogaWV0ZkBpZXRmLm9yZwo+VG86IElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VA aWV0Zi5vcmc+Cj5DYzoga2l0dGVuQGlldGYub3JnCj5TdWJqZWN0OiBba2l0dGVuXSBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLWtpdHRlbi1zYXNsLW9hdXRoLTIyLnR4dD4gKEEgc2V0IG9mCj4gICAg U0FTTCBNZWNoYW5pc21zIGZvciBPQXV0aCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQKPgo+Cj5UaGUg SUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIENvbW1vbiBBdXRoZW50aWNhdGlv biBUZWNobm9sb2d5Cj5OZXh0IEdlbmVyYXRpb24gV0cgKGtpdHRlbikgdG8gY29uc2lkZXIgdGhl IGZvbGxvd2luZyBkb2N1bWVudDoKPi0gJ0Egc2V0IG9mIFNBU0wgTWVjaGFuaXNtcyBmb3IgT0F1 dGgnCj4gIDxkcmFmdC1pZXRmLWtpdHRlbi1zYXNsLW9hdXRoLTIyLnR4dD4gYXMgUHJvcG9zZWQg U3RhbmRhcmQKPgo+VGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0 IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzCj5maW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4g UGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlCj5pZXRmQGlldGYub3JnIG1h aWxpbmcgbGlzdHMgYnkgMjAxNS0wNS0xNC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJl Cj5zZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSBy ZXRhaW4gdGhlCj5iZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0 ZWQgc29ydGluZy4KPgo+QWJzdHJhY3QKPgo+Cj4gICBPQXV0aCBlbmFibGVzIGEgdGhpcmQtcGFy dHkgYXBwbGljYXRpb24gdG8gb2J0YWluIGxpbWl0ZWQgYWNjZXNzIHRvIGEKPiAgIHByb3RlY3Rl ZCByZXNvdXJjZSwgZWl0aGVyIG9uIGJlaGFsZiBvZiBhIHJlc291cmNlIG93bmVyIGJ5Cj4gICBv cmNoZXN0cmF0aW5nIGFuIGFwcHJvdmFsIGludGVyYWN0aW9uLCBvciBieSBhbGxvd2luZyB0aGUg dGhpcmQtcGFydHkKPiAgIGFwcGxpY2F0aW9uIHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRzIG93biBi ZWhhbGYuCj4KPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBob3cgYW4gYXBwbGljYXRpb24gY2xp ZW50IHVzZXMgY3JlZGVudGlhbHMKPiAgIG9idGFpbmVkIHZpYSBPQXV0aCBvdmVyIHRoZSBTaW1w bGUgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyaXR5IExheWVyCj4gICAoU0FTTCkgdG8gYWNjZXNz IGEgcHJvdGVjdGVkIHJlc291cmNlIGF0IGEgcmVzb3VyY2Ugc2VydmUuICBUaGVyZWJ5LAo+ICAg aXQgZW5hYmxlcyBzY2hlbWVzIGRlZmluZWQgd2l0aGluIHRoZSBPQXV0aCBmcmFtZXdvcmsgZm9y IG5vbi1IVFRQLQo+ICAgYmFzZWQgYXBwbGljYXRpb24gcHJvdG9jb2xzLgo+Cj4gICBDbGllbnRz IHR5cGljYWxseSBzdG9yZSB0aGUgdXNlcidzIGxvbmctdGVybSBjcmVkZW50aWFsLiAgVGhpcyBk b2VzLAo+ICAgaG93ZXZlciwgbGVhZCB0byBzaWduaWZpY2FudCBzZWN1cml0eSB2dWxuZXJhYmls aXRpZXMsIGZvciBleGFtcGxlLAo+ICAgd2hlbiBzdWNoIGEgY3JlZGVudGlhbCBsZWFrcy4gIEEg c2lnbmlmaWNhbnQgYmVuZWZpdCBvZiBPQXV0aCBmb3IKPiAgIHVzYWdlIGluIHRob3NlIGNsaWVu dHMgaXMgdGhhdCB0aGUgcGFzc3dvcmQgaXMgcmVwbGFjZWQgYnkgYSBzaGFyZWQKPiAgIHNlY3Jl dCB3aXRoIGhpZ2hlciBlbnRyb3B5LCBpLmUuLCB0aGUgdG9rZW4uICBUb2tlbnMgdHlwaWNhbGx5 Cj4gICBwcm92aWRlIGxpbWl0ZWQgYWNjZXNzIHJpZ2h0cyBhbmQgY2FuIGJlIG1hbmFnZWQgYW5k IHJldm9rZWQKPiAgIHNlcGFyYXRlbHkgZnJvbSB0aGUgdXNlcidzIGxvbmctdGVybSBwYXNzd29y ZC4KPgo+Cj4KPgo+VGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQo+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC8KPgo+SUVTRyBk aXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC9iYWxsb3QvCj4KPgo+Tm8gSVBSIGRl Y2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELgo+Cj5U aGlzIGRlZmluZXMgYSB3YXkgdG8gdXNlIHRoZSBvYnNvbGV0ZSBPQVVUSDEuMGEgbWVjaGFuaXNt Cj5hcyB3ZWxsIGFuIE9BVVRIMiBtZWNoYW5pc20uIFRoYXQgaXMgZGVsaWJlcmF0ZSBhbmQgcmVh c29uYWJsZS4KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPktpdHRlbiBtYWlsaW5nIGxpc3QKPktpdHRlbkBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9raXR0ZW4KPgo+Cj4KPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQo+Cj5TdWJqZWN0OiBEaWdlc3QgRm9vdGVyCj4KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5PQXV0aCBtYWlsaW5nIGxpc3QKPk9BdXRo QGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4K Pgo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPkVuZCBvZiBPQXV0aCBEaWdlc3Qs IFZvbCA3OCwgSXNzdWUgMzEKPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK From nobody Tue May 5 12:30:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE631A873D; Tue, 5 May 2015 12:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0PiSPmsVr9e; Tue, 5 May 2015 12:30:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1507D1ACD6A; Tue, 5 May 2015 12:30:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150505193006.9155.54370.idtracker@ietfa.amsl.com> Date: Tue, 05 May 2015 12:30:06 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-29.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:30:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-29.txt Pages : 42 Date : 2015-05-05 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 5 12:30:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB1D1ACDC6; Tue, 5 May 2015 12:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Juwt74VM-bk; Tue, 5 May 2015 12:30:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F1F1B3039; Tue, 5 May 2015 12:30:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150505193018.30198.60364.idtracker@ietfa.amsl.com> Date: Tue, 05 May 2015 12:30:18 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:30:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-15.txt Pages : 18 Date : 2015-05-05 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 5 12:34:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0771A87BD; Tue, 5 May 2015 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syCavlOEY6kj; Tue, 5 May 2015 12:33:56 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604401ACDD6; Tue, 5 May 2015 12:33:54 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-f3-55491b2013bd Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.6A.03389.12B19455; Tue, 5 May 2015 15:33:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t45JXqDD015645; Tue, 5 May 2015 15:33:52 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t45JXnRX030314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 May 2015 15:33:51 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_84E071CC-8C34-4121-8065-A35EE7A94DD2"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <553AB662.7010303@cs.tcd.ie> Date: Tue, 5 May 2015 15:33:48 -0400 Message-Id: <77A2595A-807E-4CBC-86D7-EF5055BE5186@mit.edu> References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> <553A3929.3000002@cs.tcd.ie> <553AB662.7010303@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMKsWRmVeSWpSXmKPExsUixG6nrqso7RlqcPsMl8W0n6/ZLGb8mchs cXvuSjaLk29fsVlM33uN3YHVY233VTaPJUt+MgUwRXHZpKTmZJalFunbJXBlTNl4kqlgq2TF 7O3H2RsYT4p0MXJySAiYSGz//YoZwhaTuHBvPVsXIxeHkMBiJolH/3YzQjgbGCXOHG9ngXAe MEn87D0O1iIskCMxb+cxJhCbV8BAYu6pL0wgRcwCUxglfrz7xgIxV0qi6fUxRhCbTUBVYvqa FrAGTgFNiSfTPoPFWQRUJHbPaGaEaG5hlHh2fCkLxFQriYctB9khVk9mklh/sQdstYiAvsTe zeeAEhxAG+QlejalT2AUnIXkkFnIDgFJMAtoSyxb+JoZwtaU2N+9HCouL7H97RyouKXE4pk3 oOK2Erf6FjBB2HYSj6YtYl3AyLGKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10QvN7NELzWldBMj KL44Jfl3MH47qHSIUYCDUYmHdwOPR6gQa2JZcWXuIUZJDiYlUV4DKc9QIb6k/JTKjMTijPii 0pzU4kOMKkC7Hm1YfYFRiiUvPy9VSYT34HegVt6UxMqq1KJ8mDJpDhYlcd5NP/hChATSE0tS s1NTC1KLYLIyHBxKEryRIAsEi1LTUyvSMnNKENJMHJyHGCU4eICGV4HU8BYXJOYWZ6ZD5E8x KkqJ87ZKAiUEQBIZpXlwvbC0+IpRHOgtYd7NIFU8wJQK1/0KaDAT0OBVhSBXF5ckIqSkGhg9 MtcsPfVSVe716+r0uXdeusR6X/t3zf7upuBYzdJP/1JXF86w3971c72J5sMV1XPi+z/O3l3U svN/+kwB+8WCP1qN5vx8W55z7evmc4v6ZdU8Q96LvrzDcVV2r1bRwzfuKw0+856IenV/Z+Wz nVZbvl43O7vvW++SN1yOH7Y/PJhuvPPH2bnTS5RYijMSDbWYi4oTAY0C4MZmAwAA Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, "" , The IESG Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:34:04 -0000 --Apple-Mail=_84E071CC-8C34-4121-8065-A35EE7A94DD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, We=E2=80=99ve incorporated this text into the latest draft: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 Hopefully this will be sufficient to clear the DISCUSS. Thanks for your thoughtful review! =E2=80=94 Justin > On Apr 24, 2015, at 5:32 PM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 24/04/15 22:27, Justin Richer wrote: >> Stephen, I=E2=80=99ve worked on this this afternoon and this is my = proposed text: >>=20 >> The response to such a >> situation is out of scope for this specification but could = include >> filing a report with the application developer or = authorization >> server provider, attempted re-registration with different = metadata >> values, or various other methods. For instance, if the = server also >> supports a registration management mechanism such as that = defined in >> , the client = or >> developer could attempt to update the registration with = different >> metadata values. This process could also be aided by a = service >> discovery protocol such as = which >> can list a server's capabilities, allowing a client to make = a more >> informed registration request. The use of any such = management or >> discovery system is OPTIONAL and outside the scope of this >> specification. >>=20 >> Does this text work for you? >=20 > It does, nicely. >=20 > Thanks, > S. >=20 >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Apr 24, 2015, at 8:38 AM, Stephen Farrell = wrote: >>>=20 >>>=20 >>>=20 >>> On 24/04/15 13:30, Justin Richer wrote: >>>>>=20 >>>>=20 >>>> OK, so are you asking for something like: >>>>=20 >>>> "If the server supports an update mechanism such as = [Dyn-Reg-Management] >>>> and a discovery mechanism such as [OIDC-Discovery], then a smart = client >>>> could use these components to renegotiate undesirable metadata = values." >>>>=20 >>>> With both of these being informative references? I'm not opposed to = it. >>>=20 >>> That'd work for me, yes, thanks. >>>=20 >>> S. >>=20 >=20 --Apple-Mail=_84E071CC-8C34-4121-8065-A35EE7A94DD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVSRsdAAoJEDPAngkbd+w9rUsIAJun3Mt2Z2t+kxCnylvTTFCP hvU6itLr8j0o1ZLZh9VNTcK02RPBKq8OBioajKyOIxFCeKz6humludV9np9l3o9T bEBlOV9jLEYzDuZbrMR/ZhzNsYTgiP+526lz3G2nKl+iOLNIpgI5CK6uMwyuEvSu yEIsMOcY21/1lPa4W9b7QbqWYwqwRyXUofC+nDzsZaOajMMocQp3BA+yIBmJrHtX rpWEglSUZC06l6Q1HYWn5IQy3WerVQbJpqS7rU1oOCfOn9Itwb07TmptM5WjaQa2 bb5/eVXJbTdJPZLgjiu6V6LKGUd9RrJV5xXBMiWIJG0f4ExYvOUjbId+QZJXx9M= =l27i -----END PGP SIGNATURE----- --Apple-Mail=_84E071CC-8C34-4121-8065-A35EE7A94DD2-- From nobody Tue May 5 13:07:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EB11ACDE5; Tue, 5 May 2015 13:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcEMcsV8AgMf; Tue, 5 May 2015 13:07:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E421ACD42; Tue, 5 May 2015 13:07:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93062BEB3; Tue, 5 May 2015 21:07:32 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVLjmfpNHQXE; Tue, 5 May 2015 21:07:31 +0100 (IST) Received: from [10.67.44.99] (host86-187-113-0.range86-187.btcentralplus.com [86.187.113.0]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D8BD7BE8E; Tue, 5 May 2015 21:07:30 +0100 (IST) Message-ID: <554922FF.4060602@cs.tcd.ie> Date: Tue, 05 May 2015 21:07:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Justin Richer References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> <553A3929.3000002@cs.tcd.ie> <553AB662.7010303@cs.tcd.ie> <77A2595A-807E-4CBC-86D7-EF5055BE5186@mit.edu> In-Reply-To: <77A2595A-807E-4CBC-86D7-EF5055BE5186@mit.edu> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MB0XmASt28Q4pbKPR0Fkt9JKrMTGvDtPE" Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, The IESG , oauth-chairs@ietf.org, "" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:07:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MB0XmASt28Q4pbKPR0Fkt9JKrMTGvDtPE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, That's great thanks. I've cleared. Cheers, S. On 05/05/15 20:33, Justin Richer wrote: > Stephen, >=20 > We=E2=80=99ve incorporated this text into the latest draft: >=20 > https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 >=20 > Hopefully this will be sufficient to clear the DISCUSS. >=20 > Thanks for your thoughtful review! > =E2=80=94 Justin >=20 >> On Apr 24, 2015, at 5:32 PM, Stephen Farrell wrote: >> >> >> >> On 24/04/15 22:27, Justin Richer wrote: >>> Stephen, I=E2=80=99ve worked on this this afternoon and this is my pr= oposed text: >>> >>> The response to such a >>> situation is out of scope for this specification but could = include >>> filing a report with the application developer or authoriza= tion >>> server provider, attempted re-registration with different me= tadata >>> values, or various other methods. For instance, if the serve= r also >>> supports a registration management mechanism such as that de= fined in >>> , the client= or >>> developer could attempt to update the registration with diff= erent >>> metadata values. This process could also be aided by a servi= ce >>> discovery protocol such as which >>> can list a server's capabilities, allowing a client to make = a more >>> informed registration request. The use of any such managemen= t or >>> discovery system is OPTIONAL and outside the scope of this >>> specification. >>> >>> Does this text work for you? >> >> It does, nicely. >> >> Thanks, >> S. >> >> >>> >>> =E2=80=94 Justin >>> >>>> On Apr 24, 2015, at 8:38 AM, Stephen Farrell wrote: >>>> >>>> >>>> >>>> On 24/04/15 13:30, Justin Richer wrote: >>>>>> >>>>> >>>>> OK, so are you asking for something like: >>>>> >>>>> "If the server supports an update mechanism such as [Dyn-Reg-Manage= ment] >>>>> and a discovery mechanism such as [OIDC-Discovery], then a smart cl= ient >>>>> could use these components to renegotiate undesirable metadata valu= es." >>>>> >>>>> With both of these being informative references? I'm not opposed to= it. >>>> >>>> That'd work for me, yes, thanks. >>>> >>>> S. >>> >> >=20 --MB0XmASt28Q4pbKPR0Fkt9JKrMTGvDtPE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVSSMAAAoJEC88hzaAX42ijnAH/2p+jKaRMWFs6MLhQjf1K4LK ypCbcvRME5DkYHgTQIAQPlDGQvXHY6DNP4JTZF3YNK2JFw3gP2x9fgpRaSLqg3ti SgAf8iUkRPh85M/SmnBCgLC3LrY14jy8O1M71NXCIxkCtc3bSOJHbxdXxKtN8KxM 6Od1OEmahLzN8ZihvhdZDLwsz4PvbwJb+8dg1BFw9z3iJC7equbxZz6PKCAZV+5u H8rYukwkxJv5gWHbjL9YRMFy8MBl6UzSqNu4mcQM9BTWsW7J3FqeLLPqonuv+JOC 6LWiZ2fL8cVzNtxxCkHWfco9fZJUfVC61kyTdqfaGWEc2t2XdLHoLIJsTfxAxug= =Fogn -----END PGP SIGNATURE----- --MB0XmASt28Q4pbKPR0Fkt9JKrMTGvDtPE-- From nobody Tue May 5 14:11:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA121B2A35; Tue, 5 May 2015 14:11:28 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZmXMKsvEdpg; Tue, 5 May 2015 14:11:26 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D098E1A1BC3; Tue, 5 May 2015 14:11:25 -0700 (PDT) Received: by wgin8 with SMTP id n8so196791932wgi.0; Tue, 05 May 2015 14:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7Ww5CsMifLbu3PBu6ayioKa9XGs9Azss6QadEiOOoVI=; b=YKOfd0WfE/9wTN8Vfz1uJKZ5w3K5PZ9qInl9/tUw+RtYFbp3lTOABmA6Sgxj7o+tO/ Ip85+0cWod47gHk1AC2FNFrimx7mDiH1BAA66Zl6QLvnbOIBeLrvmwywi49Fm6lUSNYn w+iSueuKtxI/0P8Dp2fV/tGu5nvFM4vM9EF5qWmdS2K0JOf/aNrbK1tfFVpA70MtRvkH 0cbc/Sl4s7mCPz3RMps0IchH8tC7O5W26qFohQUDsWoq2qUizz7YreAmxi0SvMQCks0L aDvi1Stqu1neTju61c0HjoWdnH6h5u9dnX9aab9uN2OktgFs6R5z/fRI5YDeZwTegMTo qH2A== X-Received: by 10.180.208.7 with SMTP id ma7mr7945592wic.0.1430860284660; Tue, 05 May 2015 14:11:24 -0700 (PDT) Received: from [10.67.44.90] (host86-187-66-79.range86-187.btcentralplus.com. [86.187.66.79]) by mx.google.com with ESMTPSA id g14sm27343866wjs.47.2015.05.05.14.11.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 May 2015 14:11:23 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <554922FF.4060602@cs.tcd.ie> Date: Tue, 5 May 2015 22:11:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3589A8CE-067A-4282-991F-4950A97C76D6@gmail.com> References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> <553A3929.3000002@cs.tcd.ie> <553AB662.7010303@cs.tcd.ie> <77A2595A-807E-4CBC-86D7-EF5055BE5186@mit.edu> <554922FF.4060602@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , "" , The IESG , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:11:28 -0000 Thank you! Once the shepherd and I check the comments to make sure they wer= e all addressed, we'll progress the draft. Best regards, Kathleen=20 Sent from my iPhone > On May 5, 2015, at 9:07 PM, Stephen Farrell wr= ote: >=20 >=20 > Hi Justin, >=20 > That's great thanks. I've cleared. >=20 > Cheers, > S. >=20 >> On 05/05/15 20:33, Justin Richer wrote: >> Stephen, >>=20 >> We=E2=80=99ve incorporated this text into the latest draft: >>=20 >> https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 >>=20 >> Hopefully this will be sufficient to clear the DISCUSS. >>=20 >> Thanks for your thoughtful review! >> =E2=80=94 Justin >>=20 >>> On Apr 24, 2015, at 5:32 PM, Stephen Farrell = wrote: >>>=20 >>>=20 >>>=20 >>>> On 24/04/15 22:27, Justin Richer wrote: >>>> Stephen, I=E2=80=99ve worked on this this afternoon and this is my prop= osed text: >>>>=20 >>>> The response to such a >>>> situation is out of scope for this specification but could inc= lude >>>> filing a report with the application developer or authorizatio= n >>>> server provider, attempted re-registration with different metad= ata >>>> values, or various other methods. For instance, if the server a= lso >>>> supports a registration management mechanism such as that defin= ed in >>>> , the client or= >>>> developer could attempt to update the registration with differe= nt >>>> metadata values. This process could also be aided by a service >>>> discovery protocol such as w= hich >>>> can list a server's capabilities, allowing a client to make a m= ore >>>> informed registration request. The use of any such management o= r >>>> discovery system is OPTIONAL and outside the scope of this >>>> specification. >>>>=20 >>>> Does this text work for you? >>>=20 >>> It does, nicely. >>>=20 >>> Thanks, >>> S. >>>=20 >>>=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Apr 24, 2015, at 8:38 AM, Stephen Farrell wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 24/04/15 13:30, Justin Richer wrote: >>>>>>=20 >>>>>> OK, so are you asking for something like: >>>>>>=20 >>>>>> "If the server supports an update mechanism such as [Dyn-Reg-Manageme= nt] >>>>>> and a discovery mechanism such as [OIDC-Discovery], then a smart clie= nt >>>>>> could use these components to renegotiate undesirable metadata values= ." >>>>>>=20 >>>>>> With both of these being informative references? I'm not opposed to i= t. >>>>>=20 >>>>> That'd work for me, yes, thanks. >>>>>=20 >>>>> S. >=20 From nobody Mon May 11 11:00:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A291A1A8D; Mon, 11 May 2015 11:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwp7EOnPX0Z6; Mon, 11 May 2015 11:00:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC74C1ACE78; Mon, 11 May 2015 11:00:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511180000.5967.76714.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 11:00:00 -0700 Archived-At: Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Protocol Action: 'OAuth 2.0 Dynamic Client Registration Protocol' to Proposed Standard (draft-ietf-oauth-dyn-reg-29.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 18:00:08 -0000 The IESG has approved the following document: - 'OAuth 2.0 Dynamic Client Registration Protocol' (draft-ietf-oauth-dyn-reg-29.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ Technical Summary This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server and the resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. Working Group Summary The work on this document has gone through many iterations but there is strong agreement behind the document. The document has experienced working group last call twice: the first WGLC was in May 2013, which revealed different deployment preferences by various OAuth participants. Here is the link to the initial working group last call: https://www.ietf.org/mail-archive/web/oauth/current/msg11326.html To resolve those disagreements took some time and a new working group last call was started in April 2014 after the document was re-factored and controversial parts had been moved to another specification. Document Quality Various implementations of the dynamic client registration protocol exist. Examples of implementations can be found in the UMA and in the OpenID Connect context, such as phpOIDC (see https://bitbucket.org/PEOFIAMP/phpoidc) Gluu, and Cloud Identity (as reported at the Kantara Initiative website from an interop event that took place this year): http://kantarainitiative.org/confluence/display/uma/UMA1+Interop+Participants+and+Solutions Personnel Hannes Tschofenig is the document shepherd and the responsible area director is Kathleen Moriarty. IANA Note This draft establishes 2 IANA registries. The registry uses the 5226 'Specification Required' with designated expert review to an existing mailing list (oauth-ext-review@ietf.org). From nobody Mon May 11 11:01:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAF01A0041; Mon, 11 May 2015 11:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC72gtvcMbby; Mon, 11 May 2015 11:01:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2017F1ACE1D; Mon, 11 May 2015 11:01:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511180152.9423.60611.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 11:01:52 -0700 Archived-At: Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Document Action: 'OAuth 2.0 Dynamic Client Registration Management Protocol' to Experimental RFC (draft-ietf-oauth-dyn-reg-management-15.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 18:01:58 -0000 The IESG has approved the following document: - 'OAuth 2.0 Dynamic Client Registration Management Protocol' (draft-ietf-oauth-dyn-reg-management-15.txt) as Experimental RFC This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ Technical Summary This is an experimental draft. The OAuth 2.0 Dynamic Client Registration Management Protocol defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Working Group Summary The content of this specification was initially included in the Dynamic Client Registration specification. As result of discussions within the working group it was decided to separate the optional management functionality from the core registration specification. There was sentiment in the working group that other management solutions may be viable as well. It was therefore decided that the wider community would benefit from the documented protocol as a means to gain implementation and deployment experience. Document Quality There are implementations available of the specifications and all OpenID Connect implementations will support a subset of the functionality. Personnel Hannes Tschofenig is the document shepherd and Kathleen Moriarty is the responsible area director. IANA Note Designated Expert review is required to add the requested registry entries on the mailing list: oauth-ext-review@ietf.org for all specifications provided. From nobody Mon May 11 15:46:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73AD1A92DD for ; Mon, 11 May 2015 15:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUN9Pvf11Mlj for ; Mon, 11 May 2015 15:46:36 -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 E59FF1A9110 for ; Mon, 11 May 2015 15:46:35 -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 t4BMkWFn029602 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 May 2015 22:46:32 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4BMkVis013150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 May 2015 22:46:31 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4BMkVva019988; Mon, 11 May 2015 22:46:31 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 May 2015 15:46:31 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2AD2A348-47B7-44C3-B526-F011C71D12C6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <764097C28A40A64C892D3F25EEDCF07501A0ED38@024-SN2MPN2-202.024d.mgd.msft.net> Date: Mon, 11 May 2015 15:46:30 -0700 Message-Id: <5E8EDC7C-61A2-4E2D-AE4A-2FBF0F307A15@oracle.com> References: <764097C28A40A64C892D3F25EEDCF07501A0ED38@024-SN2MPN2-202.024d.mgd.msft.net> To: Amit K Gupta X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "draft-ietf-oauth-v2-http-mac@tools.ietf.org" , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2-http-mac05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 22:46:38 -0000 --Apple-Mail=_2AD2A348-47B7-44C3-B526-F011C71D12C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Amit, This has been asked before=85 > the MAC token work lead to a new set of specifications. >=20 > The overview document is here: > http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 = >=20 > Let me know if that helps. Feedback to the document set is highly > appreciated since we are about to finalize that work now. >=20 > Ciao > Hannes Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 11, 2015, at 3:03 PM, Amit K Gupta = wrote: >=20 > Hi Team, > =20 > Can you please suggest status of the document. Will MAC token will not = be standard any more. > =20 > ------------------------- > Thanks & regards, > Amit Gupta > Digital Partner Gateway > =C8 602-821-5131 | *amit.k.gupta3@aexp.com=20 > =20 >=20 > American Express made the following annotations=20 >=20 > "This message and any attachments are solely for the intended = recipient and may contain confidential or privileged information. If you = are not the intended recipient, any disclosure, copying, use, or = distribution of the information included in this message and any = attachments is prohibited. If you have received this communication in = error, please notify us by reply e-mail and immediately and permanently = delete this message and any attachments. Thank you."=20 >=20 > American Express a ajout=E9 le commentaire suivant le=20 > Ce courrier et toute pi=E8ce jointe qu'il contient sont r=E9serv=E9s = au seul destinataire indiqu=E9 et peuvent renfermer des renseignements = confidentiels et privil=E9gi=E9s. Si vous n'=EAtes pas le destinataire = pr=E9vu, toute divulgation, duplication, utilisation ou distribution du = courrier ou de toute pi=E8ce jointe est interdite. Si vous avez re=E7u = cette communication par erreur, veuillez nous en aviser par courrier et = d=E9truire imm=E9diatement le courrier et les pi=E8ces jointes. Merci.=20= >=20 --Apple-Mail=_2AD2A348-47B7-44C3-B526-F011C71D12C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Amit,

This = has been asked before=85
the MAC token work lead to a new set of specifications.

The overview document is here:
http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01=

Let me know if that helps. Feedback to = the document set is highly
appreciated since we are about = to finalize that work now.

Ciao
Hannes


On May 11, 2015, at 3:03 PM, Amit K Gupta <Amit.K.Gupta3@aexp.com> wrote:

Hi Team,

 

Can you please suggest = status of the document. Will MAC token will not be standard any = more.

 

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

Thanks & regards,

Amit Gupta

Digital Partner Gateway

=C8 = 602-821-5131 | *amit.k.gupta3@aexp.com 

 


American Express made the following annotations

"This message and any attachments are solely for the intended recipient = and may contain confidential or privileged=20 information. If you are not the intended recipient, any disclosure, = copying, use, or distribution of the information=20 included in this message and any attachments is prohibited. If you have = received this communication in error, please notify=20 us by reply e-mail and immediately and permanently delete this message = and any attachments. Thank you."

American Express a ajout=E9 le commentaire suivant le
Ce courrier et toute pi=E8ce jointe qu'il contient sont r=E9serv=E9s au = seul destinataire indiqu=E9 et peuvent renfermer des=20 renseignements confidentiels et privil=E9gi=E9s. Si vous n'=EAtes pas le = destinataire pr=E9vu, toute divulgation, duplication,=20 utilisation ou distribution du courrier ou de toute pi=E8ce jointe est = interdite. Si vous avez re=E7u cette communication par=20 erreur, veuillez nous en aviser par courrier et d=E9truire imm=E9diatement= le courrier et les pi=E8ces jointes. Merci.


= --Apple-Mail=_2AD2A348-47B7-44C3-B526-F011C71D12C6-- From nobody Tue May 12 10:44:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94DC1AC3EC for ; Mon, 11 May 2015 16:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG-hQJrGbLdp for ; Mon, 11 May 2015 16:28:50 -0700 (PDT) Received: from USNCNDC-MEG02-VH.aexp.com (USNCNDC-MEG02-VH.aexp.com [148.173.96.172]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DD61AC3E8 for ; Mon, 11 May 2015 16:28:49 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aexp.com; s=AXP.APR2014; t=1431386908; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:MIME-Version: X-CFilter-Loop; bh=TOOd/soNexAXc+od/0Lt2n /vsMta/i2d1hIH3c6J0Ks=; b=dZWhx9WWsKWDyWSgTBcKaI4K kWe5II43koz6iZkzDVmIox+9hIRsoV72Qz+EgxxEWkivqi/5dD +8+WsLvaRU7Z9+CHXrqtHy4AirQKSEGL8BiSi2pKix7KPCTkAa n9Dte75pwatRSe6tI63UcM3eIqW1FZ+a7OSOLNctGZn6lwUAMo 6NM6vEQvfczU3xDqKFZN+kjqgHq4bVC4ay8qH0ZxfWZ/9ReM5O 02uJmjK4ROhY29i7M+iya1b9E30C6GshOHehd66fP0J4uBcGMr rpTnWRwWTG7686kLJFXzz/aZtwWswh/CP6h3VdkL4dae4e/BT6 8oTP8nTswo1B9FalFw== Received: from USNCNDC-MEG01.aexp.com (unknown [148.171.141.83]) by USNCNDC-MEG02-VH.aexp.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-SHA) id 620e_0fa3_fc42fe94_1ef7_428c_ba29_aba15322bdcf; Mon, 11 May 2015 16:28:27 -0700 Received: from USNCNDC-MEG01.aexp.com (WGPCLDWA00051.gso.aexp.com [10.27.1.210]) by USNCNDC-MEG01.aexp.com with smtp (TLS: TLSv1/SSLv3,256bits,AES256-SHA) id 5989_04c0_7938aeb7_2fa3_4c22_af3b_b1b9cf5f476a; Mon, 11 May 2015 16:28:20 -0700 Received: from mail.aexp.com (unknown [148.171.244.108]) by USNCNDC-MEG01.aexp.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 27fa_1a75_e4563df4_2ff4_4aa2_a502_d4362ea0a92c; Mon, 11 May 2015 16:28:15 -0700 Received: from 024-SN2MPN2-202.024d.mgd.msft.net ([169.254.2.216]) by 024-SN1MMR2-018.024d.mgd.msft.net ([148.171.244.108]) with mapi id 14.03.0224.003; Mon, 11 May 2015 23:28:14 +0000 From: Amit K Gupta To: Phil Hunt Thread-Topic: Mail regarding draft-ietf-oauth-v2-http-mac05 Thread-Index: AdCMNlQ36ZnR6u+iSnOuXUyVXLr00gABf4MAAABKkFA= Date: Mon, 11 May 2015 23:28:13 +0000 Message-ID: <764097C28A40A64C892D3F25EEDCF07501A0EDE1@024-SN2MPN2-202.024d.mgd.msft.net> References: <764097C28A40A64C892D3F25EEDCF07501A0ED38@024-SN2MPN2-202.024d.mgd.msft.net> <5E8EDC7C-61A2-4E2D-AE4A-2FBF0F307A15@oracle.com> In-Reply-To: <5E8EDC7C-61A2-4E2D-AE4A-2FBF0F307A15@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.168.174] Content-Type: multipart/alternative; boundary="_000_764097C28A40A64C892D3F25EEDCF07501A0EDE1024SN2MPN220202_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 12 May 2015 10:44:22 -0700 Cc: "draft-ietf-oauth-v2-http-mac@tools.ietf.org" , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2-http-mac05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:28:56 -0000 --_000_764097C28A40A64C892D3F25EEDCF07501A0EDE1024SN2MPN220202_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 SGkgUGhpbCwKCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJlcGx5Li4uIQoKQ3VycmVudGx5IG9uZSBv ZiBvdXIgc3lzdGVtIHVzZXMgTUFDIC1Ub2tlbiBzcGVjaWZpY2F0aW9uIHNob3VsZCB3ZSBkaXNj b250aW51ZSBvciBkbyB5b3Ugc2VlIGFueSBpc3N1ZSB3aXRoIGNvbnRpbnVlZCB1c2Ugb2YgaXQu IEkgYW0gZ29pbmcgdGhyb3VnaCBQb1AgLUFyY2hpdGVjdHVyZSBhbmQgd2lsbCBkZWZpbml0ZWx5 IHByb3ZpZGUgZmVlZGJhY2suCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoYW5rcyAmIHJl Z2FyZHMsCkFtaXQgR3VwdGEKRGlnaXRhbCBQYXJ0bmVyIEdhdGV3YXkKyCA2MDItODIxLTUxMzEg fCAqYW1pdC5rLmd1cHRhM0BhZXhwLmNvbQoKRnJvbTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb21dClNlbnQ6IE1vbmRheSwgTWF5IDExLCAyMDE1IDM6NDcgUE0KVG86IEFt aXQgSyBHdXB0YQpDYzogZHJhZnQtaWV0Zi1vYXV0aC12Mi1odHRwLW1hY0B0b29scy5pZXRmLm9y Zzsgb2F1dGhAaWV0Zi5vcmcgV0cKU3ViamVjdDogUmU6IE1haWwgcmVnYXJkaW5nIGRyYWZ0LWll dGYtb2F1dGgtdjItaHR0cC1tYWMwNQoKQW1pdCwKClRoaXMgaGFzIGJlZW4gYXNrZWQgYmVmb3Jl Li4uCnRoZSBNQUMgdG9rZW4gd29yayBsZWFkIHRvIGEgbmV3IHNldCBvZiBzcGVjaWZpY2F0aW9u cy4KClRoZSBvdmVydmlldyBkb2N1bWVudCBpcyBoZXJlOgpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDEKCkxldCBtZSBrbm93IGlm IHRoYXQgaGVscHMuIEZlZWRiYWNrIHRvIHRoZSBkb2N1bWVudCBzZXQgaXMgaGlnaGx5CmFwcHJl Y2lhdGVkIHNpbmNlIHdlIGFyZSBhYm91dCB0byBmaW5hbGl6ZSB0aGF0IHdvcmsgbm93LgoKQ2lh bwpIYW5uZXMKClBoaWwKCkBpbmRlcGVuZGVudGlkCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRw Oi8vd3d3LmluZGVwZW5kZW50aWQuY29tPgpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+CgpPbiBNYXkgMTEsIDIwMTUsIGF0IDM6MDMgUE0sIEFtaXQgSyBH dXB0YSA8QW1pdC5LLkd1cHRhM0BhZXhwLmNvbTxtYWlsdG86QW1pdC5LLkd1cHRhM0BhZXhwLmNv bT4+IHdyb3RlOgoKSGkgVGVhbSwKCkNhbiB5b3UgcGxlYXNlIHN1Z2dlc3Qgc3RhdHVzIG9mIHRo ZSBkb2N1bWVudC4gV2lsbCBNQUMgdG9rZW4gd2lsbCBub3QgYmUgc3RhbmRhcmQgYW55IG1vcmUu CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoYW5rcyAmIHJlZ2FyZHMsCkFtaXQgR3VwdGEK RGlnaXRhbCBQYXJ0bmVyIEdhdGV3YXkKyCA2MDItODIxLTUxMzEgfCAqYW1pdC5rLmd1cHRhM0Bh ZXhwLmNvbTxtYWlsdG86YW1pdC5rLmd1cHRhM0BhZXhwLmNvbT4KCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpBbWVyaWNhbiBFeHByZXNzIG1hZGUgdGhlIGZvbGxvd2luZyBhbm5v dGF0aW9ucwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKIlRoaXMgbWVzc2FnZSBh bmQgYW55IGF0dGFjaG1lbnRzIGFyZSBzb2xlbHkgZm9yIHRoZSBpbnRlbmRlZCByZWNpcGllbnQg YW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgY29w eWluZywgdXNlLCBvciBkaXN0cmlidXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIGluY2x1ZGVkIGlu IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1 cyBieSByZXBseSBlLW1haWwgYW5kIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdS4iCgpBbWVyaWNhbiBF eHByZXNzIGEgYWpvdXTpIGxlIGNvbW1lbnRhaXJlIHN1aXZhbnQgbGUKQ2UgY291cnJpZXIgZXQg dG91dGUgcGnoY2Ugam9pbnRlIHF1J2lsIGNvbnRpZW50IHNvbnQgculzZXJ26XMgYXUgc2V1bCBk ZXN0aW5hdGFpcmUgaW5kaXF16SBldCBwZXV2ZW50IHJlbmZlcm1lciBkZXMgcmVuc2VpZ25lbWVu dHMgY29uZmlkZW50aWVscyBldCBwcml2aWzpZ2npcy4gU2kgdm91cyBuJ+p0ZXMgcGFzIGxlIGRl c3RpbmF0YWlyZSBwcul2dSwgdG91dGUgZGl2dWxnYXRpb24sIGR1cGxpY2F0aW9uLCB1dGlsaXNh dGlvbiBvdSBkaXN0cmlidXRpb24gZHUgY291cnJpZXIgb3UgZGUgdG91dGUgcGnoY2Ugam9pbnRl IGVzdCBpbnRlcmRpdGUuIFNpIHZvdXMgYXZleiByZed1IGNldHRlIGNvbW11bmljYXRpb24gcGFy IGVycmV1ciwgdmV1aWxsZXogbm91cyBlbiBhdmlzZXIgcGFyIGNvdXJyaWVyIGV0IGTpdHJ1aXJl IGltbelkaWF0ZW1lbnQgbGUgY291cnJpZXIgZXQgbGVzIHBp6GNlcyBqb2ludGVzLiBNZXJjaS4K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCgoKCkFtZXJpY2FuIEV4cHJlc3MgbWFk ZSB0aGUgZm9sbG93aW5nIGFubm90YXRpb25zDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiJUaGlz IG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgc29sZWx5IGZvciB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Ns b3N1cmUsIGNvcHlpbmcsIHVzZSwgb3IgZGlzdHJpYnV0aW9uIG9mIHRoZSBpbmZvcm1hdGlvbiBp bmNsdWRlZCBpbiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBpcyBwcm9oaWJpdGVk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIGFuZCBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5b3UuIg0K DQpBbWVyaWNhbiBFeHByZXNzIGEgYWpvdXTpIGxlIGNvbW1lbnRhaXJlIHN1aXZhbnQgbGUgQ2Ug Y291cnJpZXIgZXQgdG91dGUgcGnoY2Ugam9pbnRlIHF1J2lsIGNvbnRpZW50IHNvbnQgculzZXJ2 6XMgYXUgc2V1bCBkZXN0aW5hdGFpcmUgaW5kaXF16SBldCBwZXV2ZW50IHJlbmZlcm1lciBkZXMg DQpyZW5zZWlnbmVtZW50cyBjb25maWRlbnRpZWxzIGV0IHByaXZpbOlnaelzLiBTaSB2b3VzIG4n 6nRlcyBwYXMgbGUgZGVzdGluYXRhaXJlIHBy6XZ1LCB0b3V0ZSBkaXZ1bGdhdGlvbiwgZHVwbGlj YXRpb24sIHV0aWxpc2F0aW9uIG91IGRpc3RyaWJ1dGlvbiBkdSBjb3VycmllciBvdSBkZSB0b3V0 ZSBwaehjZSBqb2ludGUgZXN0IGludGVyZGl0ZS4gU2kgdm91cyBhdmV6IHJl53UgY2V0dGUgY29t bXVuaWNhdGlvbiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBub3VzIGVuIGF2aXNlciBwYXIgY291cnJp ZXIgZXQgZOl0cnVpcmUgaW1t6WRpYXRlbWVudCBsZSBjb3VycmllciBldCBsZXMgcGnoY2VzIGpv aW50ZXMuIE1lcmNpLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --_000_764097C28A40A64C892D3F25EEDCF07501A0EDE1024SN2MPN220202_ Content-Type: text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+CjwhLS1b aWYgIW1zb10+PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQj Vk1MKTt9Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQo8L3N0eWxlPjwhW2Vu ZGlmXS0tPjxzdHlsZT48IS0tCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2Zv bnQtZmFtaWx5OkhlbHZldGljYTsKCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30KQGZv bnQtZmFjZQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsKCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAg MCAwIDA7fQpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7CglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9CkBmb250LWZhY2UKCXtmb250LWZhbWls eTpUYWhvbWE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9CkBmb250LWZhY2UKCXtm b250LWZhbWlseTpXZWJkaW5nczsKCXBhbm9zZS0xOjUgMyAxIDIgMSA1IDkgNiA3IDM7fQpAZm9u dC1mYWNlCgl7Zm9udC1mYW1pbHk6IkJsYWNrYWRkZXIgSVRDIjsKCXBhbm9zZS0xOjQgMiA1IDUg NSAxNiA3IDIgMTMgMjt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGluOwoJbWFyZ2luLWJvdHRvbTouMDAw MXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJ Y29sb3I6Ymx1ZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJw bGU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9CnNwYW4uRW1haWxTdHlsZTE4Cgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi OwoJY29sb3I6d2luZG93dGV4dDt9CnNwYW4uRW1haWxTdHlsZTE5Cgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJY29s b3I6IzFGNDk3RDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 Cglmb250LXNpemU6MTAuMHB0O30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6ZTo4LjVpbiAxMS4w aW47CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQpkaXYuV29yZFNlY3Rpb24xCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPgo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPgo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPgo8L2hlYWQ+Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIFBoaWwsPG86cD48L286cD48L3Nw YW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+TWFueSB0aGFua3MgZm9yIHlvdXIgcmVwbHkmIzgyMzA7ITxv OnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkN1cnJlbnRseSBvbmUgb2Ygb3VyIHN5 c3RlbSB1c2VzIE1BQyAmIzgyMTE7VG9rZW4gc3BlY2lmaWNhdGlvbiBzaG91bGQgd2UgZGlzY29u dGludWUgb3IgZG8geW91IHNlZSBhbnkgaXNzdWUgd2l0aCBjb250aW51ZWQgdXNlIG9mIGl0LiBJ IGFtIGdvaW5nIHRocm91Z2ggUG9QICYjODIxMTtBcmNoaXRlY3R1cmUgYW5kIHdpbGwgZGVmaW5p dGVseSBwcm92aWRlIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGFua3MgJmFt cDsgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5BbWl0IEd1cHRhPG86cD48L286cD48L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+RGlnaXRh bCBQYXJ0bmVyIEdhdGV3YXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OldlYmRpbmdzO2Nv bG9yOiMyRjJGMkYiPsg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiA2MDItODIx LTUxMzEgfDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOiMxRjQ5N0Qi Pgo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMkYyRjJG Ij4qPC9zcGFuPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMwMDcwQzAi PmFtaXQuay5ndXB0YTNAYWV4cC5jb20mbmJzcDsKPC9zcGFuPjwvdT48dT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCbGFja2FkZGVyIElUQyZxdW90Oztj b2xvcjojMDA3MEMwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb21dCjxicj4KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDExLCAyMDE1IDM6NDcgUE08 YnI+CjxiPlRvOjwvYj4gQW1pdCBLIEd1cHRhPGJyPgo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtb2F1 dGgtdjItaHR0cC1tYWNAdG9vbHMuaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnIFdHPGJyPgo8Yj5T dWJqZWN0OjwvYj4gUmU6IE1haWwgcmVnYXJkaW5nIGRyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC1t YWMwNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW1pdCw8bzpw PjwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGhhcyBiZWVuIGFza2Vk IGJlZm9yZSYjODIzMDs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj50aGUgTUFDIHRva2VuIHdvcmsgbGVhZCB0byBhIG5ldyBzZXQgb2Ygc3BlY2lmaWNh dGlvbnMuPGJyPgo8YnI+ClRoZSBvdmVydmlldyBkb2N1bWVudCBpcyBoZXJlOjxicj4KPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wb3AtYXJjaGl0 ZWN0dXJlLTAxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBv cC1hcmNoaXRlY3R1cmUtMDE8L2E+PGJyPgo8YnI+CkxldCBtZSBrbm93IGlmIHRoYXQgaGVscHMu IEZlZWRiYWNrIHRvIHRoZSBkb2N1bWVudCBzZXQgaXMgaGlnaGx5PGJyPgphcHByZWNpYXRlZCBz aW5jZSB3ZSBhcmUgYWJvdXQgdG8gZmluYWxpemUgdGhhdCB3b3JrIG5vdy48YnI+Cjxicj4KQ2lh bzxicj4KSGFubmVzPG86cD48L286cD48L3A+CjwvYmxvY2txdW90ZT4KPGRpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2 Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2Pgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5k ZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJo dHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86 cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pgo8L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+ CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+CjxkaXY+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXkg MTEsIDIwMTUsIGF0IDM6MDMgUE0sIEFtaXQgSyBHdXB0YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFt aXQuSy5HdXB0YTNAYWV4cC5jb20iPkFtaXQuSy5HdXB0YTNAYWV4cC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBUZWFtLDxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHlvdSBwbGVhc2Ugc3VnZ2VzdCBzdGF0dXMgb2YgdGhlIGRv Y3VtZW50LiBXaWxsIE1BQyB0b2tlbiB3aWxsIG5vdCBiZSBzdGFuZGFyZCBhbnkgbW9yZS48bzpw PjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhbmtzICZhbXA7IHJlZ2FyZHMsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+QW1pdCBHdXB0YTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkRpZ2l0YWwgUGFydG5lciBHYXRld2F5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpXZWJkaW5ncztjb2xvcjojMkYyRjJGIj7IPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4gNjAyLTgyMS01MTMxIHw8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzO2NvbG9yOiMyRjJGMkYiPio8L3NwYW4+PHU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6IzAwNzBDMCI+PGEgaHJlZj0ibWFpbHRvOmFtaXQuay5ndXB0YTNA YWV4cC5jb20iPmFtaXQuay5ndXB0YTNAYWV4cC5jb208L2E+Jm5ic3A7Cjwvc3Bhbj48L3U+PG86 cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8 ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXYgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPgo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWdu PSJjZW50ZXIiPgo8L3NwYW4+PC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+QW1lcmljYW4gRXhwcmVzcyBtYWRlIHRoZSBmb2xsb3dpbmcg YW5ub3RhdGlvbnMKPG86cD48L286cD48L3NwYW4+PC9wPgo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVy Ij4KPC9zcGFuPjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxicj4KJnF1b3Q7VGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIHNvbGVseSBmb3IgdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCB1c2UsIG9yIGRpc3Ry aWJ1dGlvbiBvZiB0aGUgaW5mb3JtYXRpb24gaW5jbHVkZWQgaW4gdGhpcyBtZXNzYWdlCiBhbmQg YW55IGF0dGFjaG1lbnRzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg Y29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwg YW5kIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBh bnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdS4mcXVvdDsKPGJyPgo8YnI+CkFtZXJpY2FuIEV4cHJl c3MgYSBham91dOkgbGUgY29tbWVudGFpcmUgc3VpdmFudCBsZSA8YnI+CkNlIGNvdXJyaWVyIGV0 IHRvdXRlIHBp6GNlIGpvaW50ZSBxdSdpbCBjb250aWVudCBzb250IHLpc2VydulzIGF1IHNldWwg ZGVzdGluYXRhaXJlIGluZGlxdekgZXQgcGV1dmVudCByZW5mZXJtZXIgZGVzIHJlbnNlaWduZW1l bnRzIGNvbmZpZGVudGllbHMgZXQgcHJpdmls6Wdp6XMuIFNpIHZvdXMgbifqdGVzIHBhcyBsZSBk ZXN0aW5hdGFpcmUgcHLpdnUsIHRvdXRlIGRpdnVsZ2F0aW9uLCBkdXBsaWNhdGlvbiwgdXRpbGlz YXRpb24gb3UgZGlzdHJpYnV0aW9uCiBkdSBjb3VycmllciBvdSBkZSB0b3V0ZSBwaehjZSBqb2lu dGUgZXN0IGludGVyZGl0ZS4gU2kgdm91cyBhdmV6IHJl53UgY2V0dGUgY29tbXVuaWNhdGlvbiBw YXIgZXJyZXVyLCB2ZXVpbGxleiBub3VzIGVuIGF2aXNlciBwYXIgY291cnJpZXIgZXQgZOl0cnVp cmUgaW1t6WRpYXRlbWVudCBsZSBjb3VycmllciBldCBsZXMgcGnoY2VzIGpvaW50ZXMuIE1lcmNp Lgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPgo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPgo8L3NwYW4+ PC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvZGl2 Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+Cjwv ZGl2Pgo8L2Rpdj4KCjxESVY+PFA+PEhSPgpBbWVyaWNhbiBFeHByZXNzIG1hZGUgdGhlIGZvbGxv d2luZyBhbm5vdGF0aW9ucyA8YnI+Cjxocj48YnI+CiJUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgc29sZWx5IGZvciB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCAKCmluZm9ybWF0aW9uLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgdXNl LCBvciBkaXN0cmlidXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIAoKaW5jbHVkZWQgaW4gdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IAoKdXMgYnkg cmVwbHkgZS1tYWlsIGFuZCBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5b3UuIiA8YnI+PGJyPgpBbWVyaWNh biBFeHByZXNzIGEgYWpvdXQmZWFjdXRlOyBsZSBjb21tZW50YWlyZSBzdWl2YW50IGxlIDxicj4K Q2UgY291cnJpZXIgZXQgdG91dGUgcGkmZWdyYXZlO2NlIGpvaW50ZSBxdSdpbCBjb250aWVudCBz b250IHImZWFjdXRlO3NlcnYmZWFjdXRlO3MgYXUgc2V1bCBkZXN0aW5hdGFpcmUgaW5kaXF1JmVh Y3V0ZTsgZXQgcGV1dmVudCByZW5mZXJtZXIgZGVzIAoKcmVuc2VpZ25lbWVudHMgY29uZmlkZW50 aWVscyBldCBwcml2aWwmZWFjdXRlO2dpJmVhY3V0ZTtzLiBTaSB2b3VzIG4nJmVjaXJjO3RlcyBw YXMgbGUgZGVzdGluYXRhaXJlIHByJmVhY3V0ZTt2dSwgdG91dGUgZGl2dWxnYXRpb24sIGR1cGxp Y2F0aW9uLCAKCnV0aWxpc2F0aW9uIG91IGRpc3RyaWJ1dGlvbiBkdSBjb3VycmllciBvdSBkZSB0 b3V0ZSBwaSZlZ3JhdmU7Y2Ugam9pbnRlIGVzdCBpbnRlcmRpdGUuIFNpIHZvdXMgYXZleiByZSZj Y2VkaWw7dSBjZXR0ZSBjb21tdW5pY2F0aW9uIHBhciAKCmVycmV1ciwgdmV1aWxsZXogbm91cyBl biBhdmlzZXIgcGFyIGNvdXJyaWVyIGV0IGQmZWFjdXRlO3RydWlyZSBpbW0mZWFjdXRlO2RpYXRl bWVudCBsZSBjb3VycmllciBldCBsZXMgcGkmZWdyYXZlO2NlcyBqb2ludGVzLiBNZXJjaS4gPGJy Pgo8aHI+CjwvUD48L0RJVj4KPC9ib2R5Pgo8L2h0bWw+Cg== --_000_764097C28A40A64C892D3F25EEDCF07501A0EDE1024SN2MPN220202_-- From nobody Sat May 16 16:11:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA81A1B13; Sat, 16 May 2015 16:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpnU0g0rDGUR; Sat, 16 May 2015 16:11:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 466A41A87E3; Sat, 16 May 2015 16:11:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150516231112.3017.18956.idtracker@ietfa.amsl.com> Date: Sat, 16 May 2015 16:11:12 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 23:11:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-11.txt Pages : 18 Date : 2015-05-16 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-spop-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-11 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 Sat May 16 16:12:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506041A87E9 for ; Sat, 16 May 2015 16:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBoGhaxZ6AMD for ; Sat, 16 May 2015 16:12:36 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (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 9790E1A87E7 for ; Sat, 16 May 2015 16:12:36 -0700 (PDT) Received: by qcbgu10 with SMTP id gu10so73830454qcb.2 for ; Sat, 16 May 2015 16:12:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=PSfHCFNYkVduOWBYG7SMhIOhdRN2kARInsT2gquyK5c=; b=TIe2fkaGiAggc34SNzS6JvdxTSECA00v3XBDd/kXB8uI+WEpBCPs7XkNQsgQsxOx+5 lPlAGGhGWQsFwmGuUYK7tcO6LjAl/0vMGKt6QohniPVPGVoFSh7D1pnEw0Ftckp2ym53 jaDeiFGxXTROhbnvwu/EenJne71ZAzGQ5uchop6RHL4p6ESDKUaaN7i1BpvSia8pqUby WytNpLhM6pEznXmkfh21AhRowpVXanIwaXHWDHuL4/F1p13v8uiPotDZW/iniq8Vhc7b gJMt0Il2/MaBsdD1skUAiSnAfSvN5W44JgADjELzybhDD0hULSc13CnkIcoZ+f3Gcbmj cd7Q== X-Gm-Message-State: ALoCoQnNm44TFON7dpoRC3bt71IpdCj2W6dMKBIfFoyc2mi9kRvz3cWGtB4uTn/dCdFszliy43Tt X-Received: by 10.140.104.13 with SMTP id z13mr217113qge.76.1431817955836; Sat, 16 May 2015 16:12:35 -0700 (PDT) Received: from [192.168.8.100] ([181.202.15.238]) by mx.google.com with ESMTPSA id u95sm3949978qge.16.2015.05.16.16.12.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 May 2015 16:12:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: Date: Sat, 16 May 2015 20:12:24 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <89A5F51C-DE0E-4B8D-9D3B-6D1142A31859@ve7jtb.com> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-spop-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 23:12:38 -0000 Hi Kathleen, I have made the two edits and updated the draft. John B. > On Apr 18, 2015, at 12:39 PM, Kathleen Moriarty = wrote: >=20 > Hello, >=20 > I just reviewed draft-ietf-oauth-spop-10 and am thinking more should = be said about TLS 1.2 in the security recommendations. I see that it is = recommended through RFC6819 that just says:=20 >=20 > Attacks can be mitigated by using transport-layer mechanisms such as > TLS [RFC5246]. A virtual private network (VPN), e.g., based on = IPsec > VPNs [RFC4301], may be considered as well. >=20 >=20 > And more has been said in recent publications. Since this particular = draft is addressing a threat exposed when TLS is not in use, the = language from the last draft would be better, requiring at least TLS 1.2 = and referring to the TLS BCP. >=20 > The only other point from my review is a nit: > At the end of section 4.4, there should be quotes around both = instances of "plain". >=20 > Once this has been addressed, we can start IETF last call. >=20 > Thank you! > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat May 16 19:31:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383651A1B5A for ; Sat, 16 May 2015 19:31:38 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZJwwIz_5oXb for ; Sat, 16 May 2015 19:31:36 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619E71A1B56 for ; Sat, 16 May 2015 19:31:36 -0700 (PDT) Received: by qkgx75 with SMTP id x75so92140449qkg.1 for ; Sat, 16 May 2015 19:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K8wCH7Nn9asNphH10Nju0vQ/wIt1xvJQRwKgllrL9UQ=; b=S+JslPOi7iZEl0Yc9Xe8fF/5D/LfOzgh9fWUVCaSNFLz5Yk76kkfDDcxH48eABtXaY xSnfcz1EeMrsZlBABRmuwXsZEAUpA9x4z9e1pzEXunU4xcnmI8OiacN2dDP8+rk1PJIM 4orFyWm2IY/KyprprxWDCFOkW01VHOvtZosDIBLowKMHbBYYNP1plKT5HWjDHk2JXVTz dl2wNCfLPcsfZJDqxxlfQHyip6Wqy4raJcEJkCv+o3zAZSIiao5/f2Q5WMjO4LZ2z41O Tx0/9hNKXRJdFtLg0/EzhDTeC4JqTuZkxR76/MeL453E6d9/jR35dWtEyg3wTh6liZxt JZiw== X-Received: by 10.140.19.169 with SMTP id 38mr21023360qgh.75.1431829895644; Sat, 16 May 2015 19:31:35 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id 75sm4188968qhw.41.2015.05.16.19.31.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 May 2015 19:31:34 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <89A5F51C-DE0E-4B8D-9D3B-6D1142A31859@ve7jtb.com> Date: Sat, 16 May 2015 22:31:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <89A5F51C-DE0E-4B8D-9D3B-6D1142A31859@ve7jtb.com> To: John Bradley Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-spop-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 02:31:38 -0000 Hi John, Thank you. I'll review it tomorrow and start the processing so last call ca= n start on Monday. Best regards, Kathleen=20 Sent from my iPhone > On May 16, 2015, at 7:12 PM, John Bradley wrote: >=20 > Hi Kathleen, >=20 > I have made the two edits and updated the draft. >=20 > John B. >=20 >> On Apr 18, 2015, at 12:39 PM, Kathleen Moriarty wrote: >>=20 >> Hello, >>=20 >> I just reviewed draft-ietf-oauth-spop-10 and am thinking more should be s= aid about TLS 1.2 in the security recommendations. I see that it is recomme= nded through RFC6819 that just says:=20 >>=20 >> Attacks can be mitigated by using transport-layer mechanisms such as >> TLS [RFC5246]. A virtual private network (VPN), e.g., based on IPsec >> VPNs [RFC4301], may be considered as well. >>=20 >>=20 >> And more has been said in recent publications. Since this particular dra= ft is addressing a threat exposed when TLS is not in use, the language from t= he last draft would be better, requiring at least TLS 1.2 and referring to t= he TLS BCP. >>=20 >> The only other point from my review is a nit: >> At the end of section 4.4, there should be quotes around both instances o= f "plain". >>=20 >> Once this has been addressed, we can start IETF last call. >>=20 >> Thank you! >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Mon May 18 09:22:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B021ACEFD; Mon, 18 May 2015 09:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLu4i2ONgrpe; Mon, 18 May 2015 09:22:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 362D31ACF56; Mon, 18 May 2015 09:22:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150518162209.6236.25620.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 09:22:09 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Token Introspection) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:22:12 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Token Introspection' 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 2015-06-01. 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 method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon May 18 09:32:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE611AD06C; Mon, 18 May 2015 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fsw-pkqB_jy; Mon, 18 May 2015 09:32:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C91A916B; Mon, 18 May 2015 09:32:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150518163226.15138.47084.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 09:32:26 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (Proof Key for Code Exchange by OAuth Public Clients) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:32:29 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Proof Key for Code Exchange by OAuth Public Clients' 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 2015-06-01. 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 OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue May 19 16:43:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806221A1B89; Tue, 19 May 2015 16:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH8KSa4aaB9i; Tue, 19 May 2015 16:43:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B6E6A1A1A69; Tue, 19 May 2015 16:43:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C1E071832BB; Tue, 19 May 2015 16:41:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150519234149.C1E071832BB@rfc-editor.org> Date: Tue, 19 May 2015 16:41:49 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7519 on JSON Web Token (JWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:43:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7519 Title: JSON Web Token (JWT) Author: M. Jones, J. Bradley, N. Sakimura Status: Standards Track Stream: IETF Date: May 2015 Mailbox: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp Pages: 30 Characters: 63039 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-json-web-token-32.txt URL: https://www.rfc-editor.org/info/rfc7519 DOI: http://dx.doi.org/10.17487/RFC7519 JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue May 19 16:44:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE531A86E4; Tue, 19 May 2015 16:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCAZ_KEA8pO5; Tue, 19 May 2015 16:44:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id D91901A8032; Tue, 19 May 2015 16:44:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E307B1832BB; Tue, 19 May 2015 16:42:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150519234219.E307B1832BB@rfc-editor.org> Date: Tue, 19 May 2015 16:42:19 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7521 on Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:44:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7521 Title: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants Author: B. Campbell, C. Mortimore, M. Jones, Y. Goland Status: Standards Track Stream: IETF Date: May 2015 Mailbox: brian.d.campbell@gmail.com, cmortimore@salesforce.com, mbj@microsoft.com, yarong@microsoft.com Pages: 20 Characters: 44458 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-assertions-18.txt URL: https://www.rfc-editor.org/info/rfc7521 DOI: http://dx.doi.org/10.17487/RFC7521 This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue May 19 16:44:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027511A873D; Tue, 19 May 2015 16:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y44eml8BVJ-v; Tue, 19 May 2015 16:44:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 065E71A1A02; Tue, 19 May 2015 16:44:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 10FB5180452; Tue, 19 May 2015 16:42:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150519234234.10FB5180452@rfc-editor.org> Date: Tue, 19 May 2015 16:42:34 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7522 on Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:44:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7522 Title: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants Author: B. Campbell, C. Mortimore, M. Jones Status: Standards Track Stream: IETF Date: May 2015 Mailbox: brian.d.campbell@gmail.com, cmortimore@salesforce.com, mbj@microsoft.com Pages: 15 Characters: 33890 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-saml2-bearer-23.txt URL: https://www.rfc-editor.org/info/rfc7522 DOI: http://dx.doi.org/10.17487/RFC7522 This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue May 19 16:44:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DF21A8ACD; Tue, 19 May 2015 16:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Worn_wscKHs2; Tue, 19 May 2015 16:44:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A031B1A8BC1; Tue, 19 May 2015 16:44:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AA5C71832BB; Tue, 19 May 2015 16:42:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150519234252.AA5C71832BB@rfc-editor.org> Date: Tue, 19 May 2015 16:42:52 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7523 on JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:44:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7523 Title: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants Author: M. Jones, B. Campbell, C. Mortimore Status: Standards Track Stream: IETF Date: May 2015 Mailbox: mbj@microsoft.com, brian.d.campbell@gmail.com, cmortimore@salesforce.com Pages: 12 Characters: 26459 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-jwt-bearer-12.txt URL: https://www.rfc-editor.org/info/rfc7523 DOI: http://dx.doi.org/10.17487/RFC7523 This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue May 19 17:15:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5E11ACD58 for ; Tue, 19 May 2015 17:15:23 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PWix7gbhMdZ for ; Tue, 19 May 2015 17:15:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FEC1ACD55 for ; Tue, 19 May 2015 17:15:21 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.172.17; Wed, 20 May 2015 00:15:00 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0172.012; Wed, 20 May 2015 00:15:00 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Congratulations to all for getting the OAuth Assertions specs done! Thread-Index: AdCSkgH4ziwDLA4fT3+RReK15SPJJw== Date: Wed, 20 May 2015 00:14:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e0:ed43::3] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 3:zdboZ/0t7m2GB2JzHKQ0CLyZju6W2fji6q+o/F4bHbBRAH7iHyV6dnLvJert1m+GXZEkeGGGV3QGJ1cRCapndSvd4chTSXGarPl+JRl2wOdaFixVuMGnG0iAme6ItFrtPRPYpNVVLe09wHTdF02kkA==; 10:/5+32YxoTIyl5Dz6Ew6dH7yliQ66exW3q1OGPURggSkTq5DLP3p2/qA/tCh2rp7CX/CXfE5ZvmsqGC9x9RgLTPCEjEW0CdoaYB98IuYmOSU=; 6:X6yXStrYu8I/skqM82gHVdusJVv9NcrIGOBb/8EAeLDt4z1xvcep8DOCtfda0cwI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0582641F53 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(199003)(189002)(46102003)(101416001)(62966003)(92566002)(122556002)(40100003)(74316001)(2900100001)(558084003)(68736005)(15975445007)(102836002)(229853001)(2351001)(16236675004)(19617315012)(76576001)(450100001)(77156002)(19300405004)(86612001)(106356001)(189998001)(50986999)(226693001)(5001830100001)(5001960100002)(110136002)(33656002)(86362001)(54356999)(19625215002)(5001860100001)(99286002)(5001920100001)(105586002)(97736004)(5880100001)(2501003)(64706001)(77096005)(107886002)(87936001)(4001540100001)(2656002)(19580395003)(19609705001)(81156007)(48373002)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E219896963B51AE314D1F5C20BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2015 00:14:59.9283 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: [OAUTH-WG] Congratulations to all for getting the OAuth Assertions specs done! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 00:15:23 -0000 --_000_BY2PR03MB442E219896963B51AE314D1F5C20BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://self-issued.info/?p=3D1389 and @selfissued --_000_BY2PR03MB442E219896963B51AE314D1F5C20BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http:/= /self-issued.info/?p=3D1389 and @selfissued

 

--_000_BY2PR03MB442E219896963B51AE314D1F5C20BY2PR03MB442namprd_-- From nobody Wed May 20 09:01:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143721AD05D for ; Sat, 16 May 2015 00:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o09Bf7CY-X9N for ; Sat, 16 May 2015 00:43:27 -0700 (PDT) Received: from mail.dynms.de (mail.dynms.de [85.25.184.156]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973651ACF1C for ; Sat, 16 May 2015 00:43:27 -0700 (PDT) Received: from [10.10.10.101] (chello084112032036.1.11.vie.surfer.at [84.112.32.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dynms.de (Postfix) with ESMTPSA id 4CAC05461F16 for ; Sat, 16 May 2015 09:43:23 +0200 (CEST) From: Patrick Gansterer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> Date: Sat, 16 May 2015 09:43:23 +0200 To: oauth@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Wed, 20 May 2015 09:01:41 -0700 Subject: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 07:43:29 -0000 "OAuth 2.0 Dynamic Client Registration Protocol=E2=80=9D [1] is nearly = finished and provides the possibility to register additional =E2=80=9CClie= nt Metadata=E2=80=9D. OAuth 2.0 does not define any matching algorithm for the redirect_uris. = The latest information on that topic I could find is [1], which is 5 = years old. Is there any more recent discussion about it? I=E2=80=99d suggest to add an OPTIONAL = =E2=80=9Credirect_uris_matching_method=E2=80=9D client metadata. = Possible valid values could be: * =E2=80=9Cexact=E2=80=9D: The =E2=80=9Credirect_uri" provided in a = redirect-based flow must match exactly one of of the provided strings in = the =E2=80=9Credirect_uris=E2=80=9D array. * =E2=80=9Cprefix=E2=80=9D: The "redirect_uri" must begin with one of = the =E2=80=9Credirect_uris=E2=80=9D. (e.g. = "http://example.com/path/subpath=E2=80=9D would be valid with = [=E2=80=9Chttp://example.com/path/=E2=80=9C, = =E2=80=9Chttp://example.com/otherpath/=E2=80=9D]) * =E2=80=9Cregex=E2=80=9D: The provided =E2=80=9Credirect_uris=E2=80=9D = are threatened as regular expressions, which the =E2=80=9Credirect_uri=E2=80= =9D will be matched against. (e.g. = =E2=80=9Chttp://subdomain.example.com/path5/=E2=80=9C would be valid = with [=E2=80=9C^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/=E2=80=9C] If not defined the server can choose any supported method, so we do not = break existing implementations. On the other side it allows an client to = make sure that a server supports a specific matching algorithm required = by the client. ATM a client has no possibility to know how a server = handles the redirect_uris. [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html -- Patrick Gansterer From nobody Wed May 20 10:38:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3094E1A89C6 for ; Wed, 20 May 2015 10:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFQMHl9meO_L for ; Wed, 20 May 2015 10:38:31 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5671A89FA for ; Wed, 20 May 2015 10:37:38 -0700 (PDT) Received: from home.alkaline-solutions.com (c-50-155-144-64.hsd1.co.comcast.net [50.155.144.64]) by alkaline-solutions.com (Postfix) with ESMTPSA id A61C7335BF; Wed, 20 May 2015 17:37:35 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2100\)) From: David Waite In-Reply-To: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> Date: Wed, 20 May 2015 11:37:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com> References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> To: Patrick Gansterer X-Mailer: Apple Mail (2.2100) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:38:33 -0000 > On May 16, 2015, at 1:43 AM, Patrick Gansterer = wrote: >=20 > "OAuth 2.0 Dynamic Client Registration Protocol=E2=80=9D [1] is nearly = finished and provides the possibility to register additional =E2=80=9CClie= nt Metadata=E2=80=9D. >=20 > OAuth 2.0 does not define any matching algorithm for the = redirect_uris. The latest information on that topic I could find is [1], = which is 5 years old. Is there any more recent discussion about it? >=20 > I=E2=80=99d suggest to add an OPTIONAL = =E2=80=9Credirect_uris_matching_method=E2=80=9D client metadata. = Possible valid values could be: > * =E2=80=9Cexact=E2=80=9D: The =E2=80=9Credirect_uri" provided in a = redirect-based flow must match exactly one of of the provided strings in = the =E2=80=9Credirect_uris=E2=80=9D array. > * =E2=80=9Cprefix=E2=80=9D: The "redirect_uri" must begin with one of = the =E2=80=9Credirect_uris=E2=80=9D. (e.g. = "http://example.com/path/subpath=E2=80=9D would be valid with = [=E2=80=9Chttp://example.com/path/=E2=80=9C, = =E2=80=9Chttp://example.com/otherpath/=E2=80=9D]) > * =E2=80=9Cregex=E2=80=9D: The provided =E2=80=9Credirect_uris=E2=80=9D = are threatened as regular expressions, which the =E2=80=9Credirect_uri=E2=80= =9D will be matched against. (e.g. = =E2=80=9Chttp://subdomain.example.com/path5/=E2=80=9C would be valid = with [=E2=80=9C^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/=E2=80=9C] I don=E2=80=99t know if this is appropriate. For example, If a server is = unwilling to support arbitrary regex matching, how would a client which = required this be able to register dynamically? Or conversely: if a = client did not require regex matching, why would they request this from = a server? If a client requests regex or prefix, it was built to rely on these to = work. If some set of servers choose not to support regex or prefix for = scope or security reasons, this hurts interoperability from the = perspective of dynamic registration. And we already have a workaround - = instead make your client rely on the state parameter. A client doing code or implicit should specify exact return URLs in = their registration, and if they need to send the user someplace else = after authentication it should be represented to the client by their = state param. > If not defined the server can choose any supported method, so we do = not break existing implementations. On the other side it allows an = client to make sure that a server supports a specific matching algorithm = required by the client. ATM a client has no possibility to know how a = server handles the redirect_uris. The clients should be more than reasonably safe in assuming exact = matching works. If the server won=E2=80=99t support exact matching on = the redirect_uris supplied it should fail registration. -DW= From nobody Wed May 20 11:00:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55E11A8A09 for ; Wed, 20 May 2015 11:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r7qqRX5jPed for ; Wed, 20 May 2015 11:00:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 014911A8942 for ; Wed, 20 May 2015 11:00:23 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4KI0M9B028827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 20 May 2015 14:00:22 -0400 Received: from [10.10.57.144] (vpn-57-144.rdu2.redhat.com [10.10.57.144]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4KI0KdC021456 for ; Wed, 20 May 2015 14:00:21 -0400 Message-ID: <555CCBB5.3000607@redhat.com> Date: Wed, 20 May 2015 14:00:21 -0400 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: oauth@ietf.org References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com> In-Reply-To: <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:00:29 -0000 On 5/20/2015 1:37 PM, David Waite wrote: > >> On May 16, 2015, at 1:43 AM, Patrick Gansterer wrote: >> >> "OAuth 2.0 Dynamic Client Registration Protocol” [1] is nearly finished and provides the possibility to register additional “Client Metadata”. >> >> OAuth 2.0 does not define any matching algorithm for the redirect_uris. The latest information on that topic I could find is [1], which is 5 years old. Is there any more recent discussion about it? >> >> I’d suggest to add an OPTIONAL “redirect_uris_matching_method” client metadata. Possible valid values could be: >> * “exact”: The “redirect_uri" provided in a redirect-based flow must match exactly one of of the provided strings in the “redirect_uris” array. >> * “prefix”: The "redirect_uri" must begin with one of the “redirect_uris”. (e.g. "http://example.com/path/subpath” would be valid with [“http://example.com/path/“, “http://example.com/otherpath/”]) >> * “regex”: The provided “redirect_uris” are threatened as regular expressions, which the “redirect_uri” will be matched against. (e.g. “http://subdomain.example.com/path5/“ would be valid with [“^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/“] > > I don’t know if this is appropriate. For example, If a server is unwilling to support arbitrary regex matching, how would a client which required this be able to register dynamically? Or conversely: if a client did not require regex matching, why would they request this from a server? > > If a client requests regex or prefix, it was built to rely on these to work. If some set of servers choose not to support regex or prefix for scope or security reasons, this hurts interoperability from the perspective of dynamic registration. And we already have a workaround - instead make your client rely on the state parameter. > > A client doing code or implicit should specify exact return URLs in their registration, and if they need to send the user someplace else after authentication it should be represented to the client by their state param. > Nice workaround, but you are then making the client more difficult to implement and the state param larger and more complex. prefix matching seems like it would be a very common thing that an auth server supports and clients would want to have. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Wed May 20 11:44:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C063A1A8A85 for ; Wed, 20 May 2015 11:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1yEJyh4Cf2R for ; Wed, 20 May 2015 11:43:59 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E0E1A8A89 for ; Wed, 20 May 2015 11:43:59 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-06-555cd5ed1123 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id F2.AB.03355.DE5DC555; Wed, 20 May 2015 14:43:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4KIhvbU029845; Wed, 20 May 2015 14:43:57 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4KIhs2b024842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2015 14:43:56 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_ADB759CC-D860-46FA-B5D6-09EE6B868C84"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <555CCBB5.3000607@redhat.com> Date: Wed, 20 May 2015 14:43:54 -0400 Message-Id: References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com> <555CCBB5.3000607@redhat.com> To: Bill Burke X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLKsWRmVeSWpSXmKPExsUixCmqrfv2akyowf0lxha9W3cyWpx8+4rN gcljyZKfTB7v911lC2CK4rJJSc3JLEst0rdL4MrY9e4eS8F+lYptHR9YGhj/ynUxcnJICJhI LD//khnCFpO4cG89G4gtJLCYSWL2UZ4uRi4geyOjxOFvjcwQzkMmiWszrrOCVAkLmEucedLK DmLzChhIzD31hQmkiFlgCqPExzmr2CDGSkk0vT7GCGKzCahKTF/TwgRicwpoSdzo3Q82iAUo vuz/bSCbA6hZXaL9pAvETCuJrTdOs0Msnskocf3oDLBlIgJKEqt+TmADqZcQkJfo2ZQ+gVFw FpIzZiE7AyTBLKAtsWzha2YIW1Nif/dyFghbXmL72zlQcUuJxTNvQMVtJW71LWCCsO0kHk1b xLqAkWMVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrFebmaJXmpK6SZGcOxI8u1g/HpQ6RCjAAej Eg9vwYHoUCHWxLLiytxDjJIcTEqivBcvxYQK8SXlp1RmJBZnxBeV5qQWH2JUAdr1aMPqC4xS LHn5ealKIrzn1gPV8aYkVlalFuXDlElzsCiJ8276wRciJJCeWJKanZpakFoEk5Xh4FCS4L19 BahRsCg1PbUiLTOnBCHNxMF5iFGCgwdo+GaQGt7igsTc4sx0iPwpRl2OHTd/L2ISArtASpz3 PUiRAEhRRmke3BxYKnzFKA70ojDvVJAqHmAahZv0CmgJE9ASk22RIEtKEhFSUg2MklYSflYF LqGZzfN1Fv1L9utltfmyN8BZcu9D4fcr/j0tuufPsv2f8v40h+4NcZOln9xIe6P/0P7Q7DPH s+dvuvBAXfnlZ23urxLB1qfz32QGsbo75Yixm66rlourPJFQuEpfnCM6SVjTwPtg5ftuLe8T K48VsxxzETu8Qv6GrsY25y2p6QlKLMUZiYZazEXFiQCJgvA2YAMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:44:01 -0000 --Apple-Mail=_ADB759CC-D860-46FA-B5D6-09EE6B868C84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You don=E2=80=99t have to encode the parameters into the state = parameter, just have them be referenceable *from* the state parameter, = so it=E2=80=99s complexity doesn=E2=80=99t change. What I=E2=80=99ve = seen done in several implementations (including our own) is that you = generate a random State value, then save that into the session, along = with any other stateful information like an ultimate target URI or other = parameters. When the request comes back, I look back inside the session = object to see if the state value matches what I=E2=80=99d stored = earlier. If so, I can get out all the rest of the stuff that we stored = before the auth request. =E2=80=94 Justin > On May 20, 2015, at 2:00 PM, Bill Burke wrote: >=20 >=20 >=20 > On 5/20/2015 1:37 PM, David Waite wrote: >>=20 >>> On May 16, 2015, at 1:43 AM, Patrick Gansterer = wrote: >>>=20 >>> "OAuth 2.0 Dynamic Client Registration Protocol=E2=80=9D [1] is = nearly finished and provides the possibility to register additional = =E2=80=9CClient Metadata=E2=80=9D. >>>=20 >>> OAuth 2.0 does not define any matching algorithm for the = redirect_uris. The latest information on that topic I could find is [1], = which is 5 years old. Is there any more recent discussion about it? >>>=20 >>> I=E2=80=99d suggest to add an OPTIONAL = =E2=80=9Credirect_uris_matching_method=E2=80=9D client metadata. = Possible valid values could be: >>> * =E2=80=9Cexact=E2=80=9D: The =E2=80=9Credirect_uri" provided in a = redirect-based flow must match exactly one of of the provided strings in = the =E2=80=9Credirect_uris=E2=80=9D array. >>> * =E2=80=9Cprefix=E2=80=9D: The "redirect_uri" must begin with one = of the =E2=80=9Credirect_uris=E2=80=9D. (e.g. = "http://example.com/path/subpath=E2=80=9D would be valid with = [=E2=80=9Chttp://example.com/path/=E2=80=9C, = =E2=80=9Chttp://example.com/otherpath/=E2=80=9D]) >>> * =E2=80=9Cregex=E2=80=9D: The provided =E2=80=9Credirect_uris=E2=80=9D= are threatened as regular expressions, which the =E2=80=9Credirect_uri=E2= =80=9D will be matched against. (e.g. = =E2=80=9Chttp://subdomain.example.com/path5/=E2=80=9C would be valid = with [=E2=80=9C^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/=E2=80=9C] >>=20 >> I don=E2=80=99t know if this is appropriate. For example, If a server = is unwilling to support arbitrary regex matching, how would a client = which required this be able to register dynamically? Or conversely: if a = client did not require regex matching, why would they request this from = a server? >>=20 >> If a client requests regex or prefix, it was built to rely on these = to work. If some set of servers choose not to support regex or prefix = for scope or security reasons, this hurts interoperability from the = perspective of dynamic registration. And we already have a workaround - = instead make your client rely on the state parameter. >>=20 >> A client doing code or implicit should specify exact return URLs in = their registration, and if they need to send the user someplace else = after authentication it should be represented to the client by their = state param. >>=20 >=20 > Nice workaround, but you are then making the client more difficult to = implement and the state param larger and more complex. prefix matching = seems like it would be a very common thing that an auth server supports = and clients would want to have. >=20 >=20 >=20 > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_ADB759CC-D860-46FA-B5D6-09EE6B868C84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVXNXqAAoJEDPAngkbd+w9Ey0H/iEGqVM7K9pNIYabUF7/PRqz 88f/D6w8TcTCHbF5kszT/0n4APAjHfFJ47aDr23EwtCgv5kKJBTmfzCRiVcHmRXg x/mpsOfVGmenGEqJ6WFxhOhd1Va0xCgcDoACawyZKhgWa2gG0AfQcKmd1XkHte4M fgieoQsdfFkAzpiUGLREEEp5wv3SXcLtfW0mbATrkOZ36wqEzktUvn734WzizR7C SD0l7UEmQNejR9IBBNb/M7DT3er0ofUk/9qKvYOLXpZ8308gh/NX+fgd04h9JiJ8 sBIsGbJp7+g6CqV4zERrzgE2wvbzxX7BW5lgHndoDWTW44naMGIcItlLx7lxz3U= =tWe2 -----END PGP SIGNATURE----- --Apple-Mail=_ADB759CC-D860-46FA-B5D6-09EE6B868C84-- From nobody Wed May 20 19:35:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F1B1ACE88 for ; Wed, 20 May 2015 19:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYRoejFf2Xm5 for ; Wed, 20 May 2015 19:35:48 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (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 007681ACE76 for ; Wed, 20 May 2015 19:35:47 -0700 (PDT) Received: by qceb3 with SMTP id b3so31627558qce.2 for ; Wed, 20 May 2015 19:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=522JGDw8mij9YRtKE2mRqKdvqXiW9cyiuOQmRifcHwM=; b=LF+lK/T9xei1T8QQIQjk8dVqpAoAXTbR2ZTgETMTzotbN05HqvTeAN9Jmm1um08eym SzzWWxP+Pd8315qbP3hpZXXLdw7VNMO0lF50OCgjWClv1GB8Do43+pzfSfpF6TJDHMmZ M4D1+CHH5zGiHkzNU5T9uVITWMobXUDoz840Y77VTp3I6rwjBoHrByrjAps0sH4zlDO3 D7G+65FDSPXJOCKcZjCHrBgOzzN6E9MjFQNzCE82aSdifQ2qZt/Yme8o7eKZCMu+cE8Y 1e8sVvni+5mhTqZGiELT1ZXHkrRAoxXumCRoSCt76ATm0Qmx6AzDbZkaHFz4sK0M7Jsg KpqQ== X-Gm-Message-State: ALoCoQnfBp+93Gtub2NR89fXUGqnUaqbKVEKIuLZ606VtkgoHUEhdNXCw1XofKVHg0T2cRDNFmZQ X-Received: by 10.140.216.83 with SMTP id m80mr623436qhb.14.1432175747175; Wed, 20 May 2015 19:35:47 -0700 (PDT) Received: from [192.168.8.100] ([181.202.134.151]) by mx.google.com with ESMTPSA id 187sm12340029qhc.39.2015.05.20.19.35.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 19:35:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> Date: Wed, 20 May 2015 23:35:17 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <12863D78-C7CC-4E71-B4F6-09556B8E4F2B@ve7jtb.com> References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> To: Patrick Gansterer X-Mailer: Apple Mail (2.2098) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 02:35:50 -0000 I think the correct answer is that clients should always assume exact = redirect_uri matching, and servers should always enforce it. =20 Anything else is asking for trouble. If clients need to maintain some state the correct thing to do is use = the state parameter, and not append extra path or query elements to = there redirect_uri. A significant number of security problems in the wild come from servers = not enforcing this. I may be taking an excessively hard line, but partial matching is not = something we should be encouraging by making easier. I did do a draft on a way to safely use state = https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt John B. > On May 16, 2015, at 4:43 AM, Patrick Gansterer = wrote: >=20 > "OAuth 2.0 Dynamic Client Registration Protocol=E2=80=9D [1] is nearly = finished and provides the possibility to register additional =E2=80=9CClie= nt Metadata=E2=80=9D. >=20 > OAuth 2.0 does not define any matching algorithm for the = redirect_uris. The latest information on that topic I could find is [1], = which is 5 years old. Is there any more recent discussion about it? >=20 > I=E2=80=99d suggest to add an OPTIONAL = =E2=80=9Credirect_uris_matching_method=E2=80=9D client metadata. = Possible valid values could be: > * =E2=80=9Cexact=E2=80=9D: The =E2=80=9Credirect_uri" provided in a = redirect-based flow must match exactly one of of the provided strings in = the =E2=80=9Credirect_uris=E2=80=9D array. > * =E2=80=9Cprefix=E2=80=9D: The "redirect_uri" must begin with one of = the =E2=80=9Credirect_uris=E2=80=9D. (e.g. = "http://example.com/path/subpath=E2=80=9D would be valid with = [=E2=80=9Chttp://example.com/path/=E2=80=9C, = =E2=80=9Chttp://example.com/otherpath/=E2=80=9D]) > * =E2=80=9Cregex=E2=80=9D: The provided =E2=80=9Credirect_uris=E2=80=9D = are threatened as regular expressions, which the =E2=80=9Credirect_uri=E2=80= =9D will be matched against. (e.g. = =E2=80=9Chttp://subdomain.example.com/path5/=E2=80=9C would be valid = with [=E2=80=9C^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/=E2=80=9C] >=20 > If not defined the server can choose any supported method, so we do = not break existing implementations. On the other side it allows an = client to make sure that a server supports a specific matching algorithm = required by the client. ATM a client has no possibility to know how a = server handles the redirect_uris. >=20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html >=20 > -- > Patrick Gansterer >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu May 21 00:41:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700F71A6F05 for ; Thu, 21 May 2015 00:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7sat-xSwwf0 for ; Thu, 21 May 2015 00:41:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0075.outbound.protection.outlook.com [65.55.169.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBDA1A6EF4 for ; Thu, 21 May 2015 00:41:31 -0700 (PDT) Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (25.161.203.148) by BY1PR0201MB1029.namprd02.prod.outlook.com (25.161.203.147) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 07:41:29 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([25.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([25.161.203.148]) with mapi id 15.01.0166.017; Thu, 21 May 2015 07:41:29 +0000 From: Antonio Sanso To: John Bradley Thread-Topic: [OAUTH-WG] redircet_uri matching algorithm Thread-Index: AQHQkxZIC64/7LlpzE6fDYtDbYo7452Ft1+AgABZ6YA= Date: Thu, 21 May 2015 07:41:28 +0000 Message-ID: References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> <12863D78-C7CC-4E71-B4F6-09556B8E4F2B@ve7jtb.com> In-Reply-To: <12863D78-C7CC-4E71-B4F6-09556B8E4F2B@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.147.117.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1029; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0201MB1029; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1029; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(189002)(199003)(51704005)(24454002)(5001860100001)(189998001)(5001830100001)(110136002)(5001960100002)(106356001)(33656002)(106116001)(19580395003)(19580405001)(36756003)(62966003)(77156002)(82746002)(15395725005)(2950100001)(2900100001)(122556002)(50986999)(64706001)(54356999)(101416001)(76176999)(86362001)(83716003)(2656002)(66066001)(87936001)(15975445007)(40100003)(4001540100001)(1720100001)(68736005)(97736004)(92566002)(81156007)(102836002)(46102003)(105586002)(99286002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1029; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-ID: <9C2F1AA57D1B784299B3A6D0720D5EB1@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2015 07:41:28.3815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1029 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:41:34 -0000 On May 21, 2015, at 4:35 AM, John Bradley wrote: > I think the correct answer is that clients should always assume exact red= irect_uri matching, and servers should always enforce it. =20 >=20 > Anything else is asking for trouble. FWIW I completely agree with John here=85 regards antonio >=20 > If clients need to maintain some state the correct thing to do is use the= state parameter, and not append extra path or query elements to there redi= rect_uri. >=20 > A significant number of security problems in the wild come from servers n= ot enforcing this. >=20 > I may be taking an excessively hard line, but partial matching is not som= ething we should be encouraging by making easier. >=20 > I did do a draft on a way to safely use state https://tools.ietf.org/id/d= raft-bradley-oauth-jwt-encoded-state-04.txt >=20 > John B. >=20 >=20 >> On May 16, 2015, at 4:43 AM, Patrick Gansterer wrote= : >>=20 >> "OAuth 2.0 Dynamic Client Registration Protocol=94 [1] is nearly finishe= d and provides the possibility to register additional =93Client Metadata=94= . >>=20 >> OAuth 2.0 does not define any matching algorithm for the redirect_uris. = The latest information on that topic I could find is [1], which is 5 years = old. Is there any more recent discussion about it? >>=20 >> I=92d suggest to add an OPTIONAL =93redirect_uris_matching_method=94 cli= ent metadata. Possible valid values could be: >> * =93exact=94: The =93redirect_uri" provided in a redirect-based flow mu= st match exactly one of of the provided strings in the =93redirect_uris=94 = array. >> * =93prefix=94: The "redirect_uri" must begin with one of the =93redirec= t_uris=94. (e.g. "http://example.com/path/subpath=94 would be valid with [= =93http://example.com/path/=93, =93http://example.com/otherpath/=94]) >> * =93regex=94: The provided =93redirect_uris=94 are threatened as regula= r expressions, which the =93redirect_uri=94 will be matched against. (e.g. = =93http://subdomain.example.com/path5/=93 would be valid with [=93^http:\\/= \\/[a-z]+\\.example\\.com\\/path\\d+\\/=93] >>=20 >> If not defined the server can choose any supported method, so we do not = break existing implementations. On the other side it allows an client to ma= ke sure that a server supports a specific matching algorithm required by th= e client. ATM a client has no possibility to know how a server handles the = redirect_uris. >>=20 >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 >> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html >>=20 >> -- >> Patrick Gansterer >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu May 21 12:29:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28B1A889D for ; Thu, 21 May 2015 12:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgQpYX57U5O9 for ; Thu, 21 May 2015 12:29:53 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD17E1A890F for ; Thu, 21 May 2015 12:29:30 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.172.17; Thu, 21 May 2015 19:29:28 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0172.012; Thu, 21 May 2015 19:29:28 +0000 From: Mike Jones To: Antonio Sanso , John Bradley Thread-Topic: [OAUTH-WG] redircet_uri matching algorithm Thread-Index: AQHQkxZHIejCyvza/Eyad4viMNJG1J2Ft1+AgABVjACAAMWF8A== Date: Thu, 21 May 2015 19:29:27 +0000 Message-ID: References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> <12863D78-C7CC-4E71-B4F6-09556B8E4F2B@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e0:ee43::4] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 3:Pmuuy+8YdmG+YbCmVptEd3MAYZ/XRDhL20NwBOmUDcSoWvAJTuEtlfGq2EoK6M+mNT76pQ/qguTzQ1mOksNAn+aDnD7/yQcIu9BmYUcvlQ+ZXfUtGWdUSIBWPWhMLtMFvbM6o4oLifMPcy92gMFlIw==; 10:mITQpcs/Fb1zNXNvwLU1yauYh0r6YUxzwwIZlwej7dWRQTG+XDPwUW43Ihr7Fnzwr8wcVmr+8ShSnGEm4R1yYSAdQSrO7+tdpGtoXFOzRho=; 6:SjZgVHwmsOA2RW0iGkEVmi444RuWGhFqw9QUZeRoVakMwLOkFVpaygul0wj4uPib x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(199003)(377454003)(51704005)(189002)(106356001)(102836002)(15975445007)(86362001)(122556002)(64706001)(106116001)(1720100001)(68736005)(77096005)(62966003)(77156002)(40100003)(76176999)(54356999)(15395725005)(50986999)(86612001)(5001770100001)(189998001)(5001960100002)(5001860100001)(5001830100001)(19580405001)(46102003)(19580395003)(99286002)(105586002)(97736004)(2656002)(81156007)(74316001)(33656002)(101416001)(87936001)(92566002)(4001540100001)(76576001)(2950100001)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2015 19:29:28.0510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:29:55 -0000 +1 I vehemently concur that that working group should stay completely clear of= facilitating this insecure practice. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Antonio Sanso Sent: Thursday, May 21, 2015 12:41 AM To: John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm On May 21, 2015, at 4:35 AM, John Bradley wrote: > I think the correct answer is that clients should always assume exact red= irect_uri matching, and servers should always enforce it. =20 >=20 > Anything else is asking for trouble. FWIW I completely agree with John here... regards antonio >=20 > If clients need to maintain some state the correct thing to do is use the= state parameter, and not append extra path or query elements to there redi= rect_uri. >=20 > A significant number of security problems in the wild come from servers n= ot enforcing this. >=20 > I may be taking an excessively hard line, but partial matching is not som= ething we should be encouraging by making easier. >=20 > I did do a draft on a way to safely use state https://tools.ietf.org/id/d= raft-bradley-oauth-jwt-encoded-state-04.txt >=20 > John B. >=20 >=20 >> On May 16, 2015, at 4:43 AM, Patrick Gansterer wrote= : >>=20 >> "OAuth 2.0 Dynamic Client Registration Protocol" [1] is nearly finished = and provides the possibility to register additional "Client Metadata". >>=20 >> OAuth 2.0 does not define any matching algorithm for the redirect_uris. = The latest information on that topic I could find is [1], which is 5 years = old. Is there any more recent discussion about it? >>=20 >> I'd suggest to add an OPTIONAL "redirect_uris_matching_method" client me= tadata. Possible valid values could be: >> * "exact": The "redirect_uri" provided in a redirect-based flow must mat= ch exactly one of of the provided strings in the "redirect_uris" array. >> * "prefix": The "redirect_uri" must begin with one of the "redirect_uris= ". (e.g. "http://example.com/path/subpath" would be valid with ["http://exa= mple.com/path/", "http://example.com/otherpath/"]) >> * "regex": The provided "redirect_uris" are threatened as regular expres= sions, which the "redirect_uri" will be matched against. (e.g. "http://subd= omain.example.com/path5/" would be valid with ["^http:\\/\\/[a-z]+\\.exampl= e\\.com\\/path\\d+\\/"] >>=20 >> If not defined the server can choose any supported method, so we do not = break existing implementations. On the other side it allows an client to ma= ke sure that a server supports a specific matching algorithm required by th= e client. ATM a client has no possibility to know how a server handles the = redirect_uris. >>=20 >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 >> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html >>=20 >> -- >> Patrick Gansterer >>=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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu May 21 13:13:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10BB1A8A5E for ; Thu, 21 May 2015 13:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_XBL=0.375, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU8vP0g5mAW7 for ; Thu, 21 May 2015 13:13:30 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6591C1A8A60 for ; Thu, 21 May 2015 13:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432239208; bh=ZEfcNMINCZR8VikzGdOCQkVwVze0JLJmWJbroMlk+3s=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=MWNwjgip6QyVqGnFytYgrz3m/FHaQXgUR0jOzkbl5/OOXS6X29C/t7/+r0azd66SU2WS7kN+oQHf1tnQPssqzmsgejk6YXBPeg9+HrWIoEVfO9gGp8O3rb9FCTlYjpeCC8zuzwNvpYfioKq4jwHb0Q6WSg8Mjgorxmr1eVxsKi9O1DVrLevhXJbDmPnOwibTAa6KSAr0jwKB2Qwn/mMTH8sbPJ9Ifh36R+ehKMkbkXVoFEJ63oquoMAsEg/1hc5xsTzTSXX1OSjj5PU5ozb0g3KKmWCmoUlU3NHlajA2n1MZ2wWto4ZpAdX2osC789Il6eNKcx1EUBaKduGOcYueDQ== Received: from [98.139.215.142] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 21 May 2015 20:13:28 -0000 Received: from [98.139.212.204] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 21 May 2015 20:13:28 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 21 May 2015 20:13:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 531572.5620.bm@omp1013.mail.bf1.yahoo.com X-YMail-OSG: RyROJ88VM1k9qO11gnwcUorpzeJoADjElXSPnZvKzSB.zTsv4YqhRmK6z5o6EO5 8TnhHw1AzkjYf2ylBWkEsTbxeL2dADylF1aS.__jX32JtC6Kx87d4CA4azSv4y8FvZ2347JGYuui u319Zp3QDDCBOXS5.D3k9wK1Zyr9lCUv7i7BbS31aTxL7NF1r3VydTwGSwW1ySwvxX.e2_WMT2J7 C1E4wWBxqpsaTtFDYVrUS22N6PVFbePHVenmbWdvBoDSOBajeS1a4TwO3tHCgSl8hwXyDFNf281U MJrFxNJ_ITDPvU2eIdW0X6IqW.b_j1mXfa8NaCTMj0pjjcwN.XV4uORi89Bq5UYtsCYQcURYklwu u5sQH9gQA9uHc7kBZ1Gi2mtwHaG8qziZZ19.BWZuwkXlbffRMVPMHtMW40t0V8zPzH_cTG9ulgWQ SaisRZ9YlDm1vohW_Jvgt6E7UX3qCUPJ3bXg9QhVQqn1mJls2kqsFgVHyJOVv.Sri8kzghTXlXXP rhjNBoweYrhEcVLCcwQ-- Received: by 66.196.80.145; Thu, 21 May 2015 20:13:28 +0000 Date: Thu, 21 May 2015 20:13:27 +0000 (UTC) From: Bill Mills To: Mike Jones , Antonio Sanso , John Bradley Message-ID: <1842692772.4820975.1432239207731.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4820974_757761103.1432239207723" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:13:31 -0000 ------=_Part_4820974_757761103.1432239207723 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1=20 On Thursday, May 21, 2015 12:29 PM, Mike Jones wrote: =20 +1 I vehemently concur that that working group should stay completely clear of= facilitating this insecure practice. =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 Antonio Sanso Sent: Thursday, May 21, 2015 12:41 AM To: John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm On May 21, 2015, at 4:35 AM, John Bradley wrote: > I think the correct answer is that clients should always assume exact red= irect_uri matching, and servers should always enforce it.=C2=A0=20 >=20 > Anything else is asking for trouble. FWIW I completely agree with John here... regards antonio >=20 > If clients need to maintain some state the correct thing to do is use the= state parameter, and not append extra path or query elements to there redi= rect_uri. >=20 > A significant number of security problems in the wild come from servers n= ot enforcing this. >=20 > I may be taking an excessively hard line, but partial matching is not som= ething we should be encouraging by making easier. >=20 > I did do a draft on a way to safely use state https://tools.ietf.org/id/d= raft-bradley-oauth-jwt-encoded-state-04.txt >=20 > John B. >=20 >=20 >> On May 16, 2015, at 4:43 AM, Patrick Gansterer wrote= : >>=20 >> "OAuth 2.0 Dynamic Client Registration Protocol" [1] is nearly finished = and provides the possibility to register additional "Client Metadata". >>=20 >> OAuth 2.0 does not define any matching algorithm for the redirect_uris. = The latest information on that topic I could find is [1], which is 5 years = old. Is there any more recent discussion about it? >>=20 >> I'd suggest to add an OPTIONAL "redirect_uris_matching_method" client me= tadata. Possible valid values could be: >> * "exact": The "redirect_uri" provided in a redirect-based flow must mat= ch exactly one of of the provided strings in the "redirect_uris" array. >> * "prefix": The "redirect_uri" must begin with one of the "redirect_uris= ". (e.g. "http://example.com/path/subpath" would be valid with ["http://exa= mple.com/path/", "http://example.com/otherpath/"]) >> * "regex": The provided "redirect_uris" are threatened as regular expres= sions, which the "redirect_uri" will be matched against. (e.g. "http://subd= omain.example.com/path5/" would be valid with ["^http:\\/\\/[a-z]+\\.exampl= e\\.com\\/path\\d+\\/"] >>=20 >> If not defined the server can choose any supported method, so we do not = break existing implementations. On the other side it allows an client to ma= ke sure that a server supports a specific matching algorithm required by th= e client. ATM a client has no possibility to know how a server handles the = redirect_uris. >>=20 >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 >> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html >>=20 >> -- >> Patrick Gansterer >>=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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_4820974_757761103.1432239207723 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

=

On Thursday= , May 21, 2015 12:29 PM, Mike Jones <Michael.Jones@microsoft.com> wro= te:


+1

I vehemently concur that that working group sh= ould stay completely clear of facilitating this insecure practice.

         &n= bsp;      -- Mike

= -----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Antonio Sanso
Sent: Thursday, May 21, 2015 12:41 AM
To: J= ohn Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm


On May 21, 2015, at 4:35 AM, John = Bradley <ve7jtb@ve7jtb.com> wrote:

> I think the correct answer is that clients should= always assume exact redirect_uri matching, and servers should always enfor= ce it. 
>
> Anything else = is asking for trouble.

FWIW I complete= ly agree with John here...

regards

antonio


>
> If clients need to main= tain some state the correct thing to do is use the state parameter, and not= append extra path or query elements to there redirect_uri.
>
> A significant number of security problems i= n the wild come from servers not enforcing this.
> > I may be taking an excessively hard line, but partial = matching is not something we should be encouraging by making easier.
>
> I did do a draft on a way to safel= y use state https://tools.ietf.org= /id/draft-bradley-oauth-jwt-encoded-state-04.txt
>=
> John B.
>
= >
>> On May 16, 2015, at 4:43 AM, Patrick Ganst= erer <paroga@paroga.com> wrote:
&= gt;>
>> "OAuth 2.0 Dynamic Client Registration = Protocol" [1] is nearly finished and provides the possibility to register a= dditional "Client Metadata".
>>
= >> OAuth 2.0 does not define any matching algorithm for the redirect_= uris. The latest information on that topic I could find is [1], which is 5 = years old. Is there any more recent discussion about it?
= >>
>> I'd suggest to add an OPTIONAL "redire= ct_uris_matching_method" client metadata. Possible valid values could be:>> * "exact": The "redirect_uri" provided in a redir= ect-based flow must match exactly one of of the provided strings in the "re= direct_uris" array.
>> * "prefix": The "redirect_ur= i" must begin with one of the "redirect_uris". (e.g. "http://example.com/= path/subpath" would be valid with ["http://example.com/path/", "http://e= xample.com/otherpath/"])
>> * "regex": The prov= ided "redirect_uris" are threatened as regular expressions, which the "redi= rect_uri" will be matched against. (e.g. "http://subdomain.example.co= m/path5/" would be valid with ["^http:\\/\\/[a-z]+\\.example\\.com\\/pa= th\\d+\\/"]
>>
>> If not d= efined the server can choose any supported method, so we do not break exist= ing implementations. On the other side it allows an client to make sure tha= t a server supports a specific matching algorithm required by the client. A= TM a client has no possibility to know how a server handles the redirect_ur= is.
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29
>> [2] http://www.i= etf.org/mail-archive/web/oauth/current/msg02617.html
= >>
>> --
>> Patrick = Gansterer
>>
>> __________= _____________________________________
>> OAuth mail= ing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

------=_Part_4820974_757761103.1432239207723-- From nobody Thu May 21 13:25:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EE71A8A83 for ; Thu, 21 May 2015 13:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH78heOt9xJS for ; Thu, 21 May 2015 13:25:55 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (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 4ED781A8992 for ; Thu, 21 May 2015 13:25:55 -0700 (PDT) Received: from zmail12.collab.prod.int.phx2.redhat.com (zmail12.collab.prod.int.phx2.redhat.com [10.5.83.14]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LKPoYa013725; Thu, 21 May 2015 16:25:50 -0400 Date: Thu, 21 May 2015 16:25:49 -0400 (EDT) From: Pedro Igor Silva To: Antonio Sanso Message-ID: <879444027.2844650.1432239949648.JavaMail.zimbra@redhat.com> In-Reply-To: References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> <12863D78-C7CC-4E71-B4F6-09556B8E4F2B@ve7jtb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.97.5.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC43 (Linux)/8.0.6_GA_5922) Thread-Topic: [OAUTH-WG] redircet_uri matching algorithm Thread-Index: AQHQkxZIC64/7LlpzE6fDYtDbYo7452Ft1+AgABZ6YB9lN9i4g== Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:25:56 -0000 ----- Original Message ----- > From: "Antonio Sanso" > To: "John Bradley" > Cc: oauth@ietf.org > Sent: Thursday, May 21, 2015 4:41:28 AM > Subject: Re: [OAUTH-WG] redircet_uri matching algorithm >=20 >=20 > On May 21, 2015, at 4:35 AM, John Bradley wrote: >=20 > > I think the correct answer is that clients should always assume exact > > redirect_uri matching, and servers should always enforce it. > >=20 > > Anything else is asking for trouble. >=20 > FWIW I completely agree with John here=E2=80=A6 >=20 > regards >=20 > antonio +1 >=20 >=20 > >=20 > > If clients need to maintain some state the correct thing to do is use t= he > > state parameter, and not append extra path or query elements to there > > redirect_uri. > >=20 > > A significant number of security problems in the wild come from servers= not > > enforcing this. > >=20 > > I may be taking an excessively hard line, but partial matching is not > > something we should be encouraging by making easier. > >=20 > > I did do a draft on a way to safely use state > > https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt > >=20 > > John B. > >=20 > >=20 > >> On May 16, 2015, at 4:43 AM, Patrick Gansterer wro= te: > >>=20 > >> "OAuth 2.0 Dynamic Client Registration Protocol=E2=80=9D [1] is nearly= finished > >> and provides the possibility to register additional =E2=80=9CClient Me= tadata=E2=80=9D. > >>=20 > >> OAuth 2.0 does not define any matching algorithm for the redirect_uris= . > >> The latest information on that topic I could find is [1], which is 5 > >> years old. Is there any more recent discussion about it? > >>=20 > >> I=E2=80=99d suggest to add an OPTIONAL =E2=80=9Credirect_uris_matching= _method=E2=80=9D client > >> metadata. Possible valid values could be: > >> * =E2=80=9Cexact=E2=80=9D: The =E2=80=9Credirect_uri" provided in a re= direct-based flow must match > >> exactly one of of the provided strings in the =E2=80=9Credirect_uris= =E2=80=9D array. > >> * =E2=80=9Cprefix=E2=80=9D: The "redirect_uri" must begin with one of = the =E2=80=9Credirect_uris=E2=80=9D. > >> (e.g. "http://example.com/path/subpath=E2=80=9D would be valid with > >> [=E2=80=9Chttp://example.com/path/=E2=80=9C, =E2=80=9Chttp://example.c= om/otherpath/=E2=80=9D]) > >> * =E2=80=9Cregex=E2=80=9D: The provided =E2=80=9Credirect_uris=E2=80= =9D are threatened as regular > >> expressions, which the =E2=80=9Credirect_uri=E2=80=9D will be matched = against. (e.g. > >> =E2=80=9Chttp://subdomain.example.com/path5/=E2=80=9C would be valid w= ith > >> [=E2=80=9C^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/=E2=80=9C] > >>=20 > >> If not defined the server can choose any supported method, so we do no= t > >> break existing implementations. On the other side it allows an client = to > >> make sure that a server supports a specific matching algorithm require= d > >> by the client. ATM a client has no possibility to know how a server > >> handles the redirect_uris. > >>=20 > >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 > >> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html > >>=20 > >> -- > >> Patrick Gansterer > >>=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 >=20 From nobody Thu May 21 21:59:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522DF1A9102 for ; Thu, 21 May 2015 21:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_HmcBhEKLOI for ; Thu, 21 May 2015 21:59:35 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 2435C1A9100 for ; Thu, 21 May 2015 21:59:35 -0700 (PDT) Received: (qmail 12695 invoked by uid 0); 22 May 2015 04:59:34 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 22 May 2015 04:59:34 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw4 with id WysJ1q00A2is6CS01ysMbx; Fri, 22 May 2015 04:52:23 -0600 X-Authority-Analysis: v=2.1 cv=D8zUdJhj c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=UMhCEPvdHqkA:10 a=h1PgugrvaO0A:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=CjxXgO3LAAAA:8 a=48vgC7mUAAAA:8 a=yMhMjlubAAAA:8 a=Mhp_Scw7AAAA:8 a=FRLKbgmKAAAA:8 a=A1X0JdhQAAAA:8 a=ezbKcNVf1CGz8qYZWE8A:9 a=wlMw84Jn-1DgN8g1:21 a=wwBTGdFpht061CwM:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=KfHwbhnLY3UA:10 a=SSmOFEACAAAA:8 a=Vnlrxu0Y_mNYl-c7b6sA:9 a=KT8SHni5eztKEv9A:21 a=PVHk_3XDUuwWdjAQ:21 a=f94tU6mJ6O7vuYQj:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=X5faoHxxbHa5RV59tQx3ch9Wk8lT4LbVU2sy0F+uUZQ=; b=dYQUlRajs+umuBriKSfQUH3GlgKZbXlxbqP1MeZu2thepgWbNPSw+qGIx/DnjogiGuqkBgfhyvWXkN43wihFdbtKO8wxxM8l8hUOecgiTpFttobBArrg4EWBrpAVhDtO; Received: from [104.176.153.192] (port=49914 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1Yvf3R-0007o0-4q; Thu, 21 May 2015 22:59:29 -0600 From: "Donald F. Coffin" To: "'Bill Mills'" , "'Mike Jones'" , "'Antonio Sanso'" , "'John Bradley'" References: <1842692772.4820975.1432239207731.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1842692772.4820975.1432239207731.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 22 May 2015 00:59:25 -0400 Organization: REMI Networks Message-ID: <006301d0944c$15766390$40632ab0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01D0942A.8E662320" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJhc5N+hDct3Esc9dP/ZqVih7PDhAIgFNF2nFSwTJA= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 104.176.153.192 authed with donald.coffin@reminetworks.com} Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 04:59:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01D0942A.8E662320 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: = donald.coffin@reminetworks.com =20 From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 Sent: Thursday, May 21, 2015 4:13 PM To: Mike Jones; Antonio Sanso; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm =20 +1 =20 =20 On Thursday, May 21, 2015 12:29 PM, Mike Jones = > = wrote: =20 +1 I vehemently concur that that working group should stay completely clear = of facilitating this insecure practice. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Antonio Sanso Sent: Thursday, May 21, 2015 12:41 AM To: John Bradley Cc: oauth@ietf.org =20 Subject: Re: [OAUTH-WG] redircet_uri matching algorithm On May 21, 2015, at 4:35 AM, John Bradley > wrote: > I think the correct answer is that clients should always assume exact = redirect_uri matching, and servers should always enforce it. =20 >=20 > Anything else is asking for trouble. FWIW I completely agree with John here... regards antonio >=20 > If clients need to maintain some state the correct thing to do is use = the state parameter, and not append extra path or query elements to = there redirect_uri. >=20 > A significant number of security problems in the wild come from = servers not enforcing this. >=20 > I may be taking an excessively hard line, but partial matching is not = something we should be encouraging by making easier. >=20 > I did do a draft on a way to safely use state = https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt >=20 > John B. >=20 >=20 >> On May 16, 2015, at 4:43 AM, Patrick Gansterer > wrote: >>=20 >> "OAuth 2.0 Dynamic Client Registration Protocol" [1] is nearly = finished and provides the possibility to register additional "Client = Metadata". >>=20 >> OAuth 2.0 does not define any matching algorithm for the = redirect_uris. The latest information on that topic I could find is [1], = which is 5 years old. Is there any more recent discussion about it? >>=20 >> I'd suggest to add an OPTIONAL "redirect_uris_matching_method" client = metadata. Possible valid values could be: >> * "exact": The "redirect_uri" provided in a redirect-based flow must = match exactly one of of the provided strings in the "redirect_uris" = array. >> * "prefix": The "redirect_uri" must begin with one of the = "redirect_uris". (e.g. "http://example.com/path/subpath" would be valid = with ["http://example.com/path/", "http://example.com/otherpath/"]) >> * "regex": The provided "redirect_uris" are threatened as regular = expressions, which the "redirect_uri" will be matched against. (e.g. = "http://subdomain.example.com/path5/" would be valid with = ["^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/"] >>=20 >> If not defined the server can choose any supported method, so we do = not break existing implementations. On the other side it allows an = client to make sure that a server supports a specific matching algorithm = required by the client. ATM a client has no possibility to know how a = server handles the redirect_uris. >>=20 >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 >> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html >>=20 >> -- >> Patrick Gansterer >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org =20 > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_0064_01D0942A.8E662320 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO<= /p>

 

REMI = Networks

2335 Dunwoody Crossing Suite = E

Dunwoody, GA = 30338-8221

 

Phone:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (949) 636-8571

Email:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 donald.coffin@reminetworks.com

 

From:<= /b> = Bill Mills [mailto:wmills_92105@yahoo.com]
Sent: Thursday, = May 21, 2015 4:13 PM
To: Mike Jones; Antonio Sanso; John = Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = redircet_uri matching algorithm

 

= +1

=  

=  

On = Thursday, May 21, 2015 12:29 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

+1

I = vehemently concur that that working group should stay completely clear = of facilitating this insecure practice.

    =             -- = Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of Antonio Sanso
Sent: Thursday, May 21, 2015 12:41 AM
To: = John Bradley
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] redircet_uri matching algorithm


On May 21, 2015, = at 4:35 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

> I think the correct answer is that clients should = always assume exact redirect_uri matching, and servers should always = enforce it. 
>
> Anything else is asking for = trouble.

FWIW I completely agree with John = here...

regards

antonio


>
> If = clients need to maintain some state the correct thing to do is use the = state parameter, and not append extra path or query elements to there = redirect_uri.
>
> A significant number of security problems = in the wild come from servers not enforcing this.
>
> I may = be taking an excessively hard line, but partial matching is not = something we should be encouraging by making easier.
>
> I = did do a draft on a way to safely use state https://tools.ietf.org/id/draft-bradley-oauth-jwt-encod= ed-state-04.txt
>
> John B.
>
> =
>> On May 16, 2015, at 4:43 AM, Patrick Gansterer <paroga@paroga.com> = wrote:
>>
>> "OAuth 2.0 Dynamic Client = Registration Protocol" [1] is nearly finished and provides the = possibility to register additional "Client = Metadata".
>>
>> OAuth 2.0 does not define any = matching algorithm for the redirect_uris. The latest information on that = topic I could find is [1], which is 5 years old. Is there any more = recent discussion about it?
>>
>> I'd suggest to add = an OPTIONAL "redirect_uris_matching_method" client metadata. = Possible valid values could be:
>> * "exact": The = "redirect_uri" provided in a redirect-based flow must match = exactly one of of the provided strings in the "redirect_uris" = array.
>> * "prefix": The "redirect_uri" = must begin with one of the "redirect_uris". (e.g. "http://example.com/path/subpath" would be = valid with ["http://example.com/path/", "http://example.com/otherpath/"])
>> = * "regex": The provided "redirect_uris" are = threatened as regular expressions, which the "redirect_uri" = will be matched against. (e.g. "http://subdomain.example.com/path5/" would be = valid with = ["^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/"]
>>= ;
>> If not defined the server can choose any supported = method, so we do not break existing implementations. On the other side = it allows an client to make sure that a server supports a specific = matching algorithm required by the client. ATM a client has no = possibility to know how a server handles the redirect_uris.
>> =
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29<= /a>
>> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg0= 2617.html
>>
>> --
>> Patrick = Gansterer
>>
>> = _______________________________________________
>> 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

 

------=_NextPart_000_0064_01D0942A.8E662320-- From nobody Thu May 28 05:40:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890DA1A9108; Thu, 28 May 2015 05:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ7-OCO8z30I; Thu, 28 May 2015 05:40:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8BD1A9132; Thu, 28 May 2015 05:40:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528124003.17766.34518.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 05:40:03 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-30.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 12:40:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-30.txt Pages : 43 Date : 2015-05-28 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-30 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-30 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 May 28 05:40:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACAB1A9162; Thu, 28 May 2015 05:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7LYYKb2Upbr; Thu, 28 May 2015 05:40:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7F61A916A; Thu, 28 May 2015 05:40:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528124018.10774.72974.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 05:40:18 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 12:40:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-09.txt Pages : 16 Date : 2015-05-28 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-introspection-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 28 05:52:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0851A9151 for ; Thu, 28 May 2015 05:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYitgwsvd5OT for ; Thu, 28 May 2015 05:52:47 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531F81A914F for ; Thu, 28 May 2015 05:52:46 -0700 (PDT) X-AuditID: 1209190f-f79936d000000d16-59-55670f9c7af3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 20.3A.03350.D9F07655; Thu, 28 May 2015 08:52:45 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4SCqiGn023011 for ; Thu, 28 May 2015 08:52:44 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4SCqhow007471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 28 May 2015 08:52:44 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_25F78307-1FA6-4B83-BF07-9262F861ADDF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <20150528124003.17766.34518.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 08:52:42 -0400 Message-Id: <13369640-A838-42A0-8E19-343600980513@mit.edu> References: <20150528124003.17766.34518.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrTuXPz3U4OYpLouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9W394wFjZIVz3pXsTUwzhTpYuTkkBAwkdi5dyIThC0mceHe erYuRi4OIYHFTBLNUzYxQzjHGCWev7kA5Xxjkngxs4MFxGEWmMIocazzOyNIP6+AnsSjp4/Z QWxhAWeJLY/3M0PMlZJoen0MrIZNQFVi+poWoH0cHJwCThJfurxBwixA4d7d28HCvAJWEj93 gU0REnCUuNm0GswWEVCXWHP+J1iJhICsxNetchMYBWYhO2IWkiNAbGYBbYllC18zQ9iaEvu7 l7NA2PIS29/OgYpbSiyeeQMqbitxq28BE4RtJ/Fo2iLWBYwcqxhlU3KrdHMTM3OKU5N1i5MT 8/JSi3RN9HIzS/RSU0o3MYKjQZJ/B+O3g0qHGAU4GJV4eBXnpIUKsSaWFVfmHmKU5GBSEuWt 40gPFeJLyk+pzEgszogvKs1JLT7EqAK069GG1RcYpVjy8vNSlUR4j3AD1fGmJFZWpRblw5RJ c7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuDl5gNqFCxKTU+tSMvMKUFIM3FwHmKU4OAB Gs4EUsNbXJCYW5yZDpE/xagoJc47HSQhAJLIKM2D64UlsVeM4kBvCfMWgFTxABMgXPcroMFM QIPNjqaADC5JREhJNTA2Pg/U0uEUFi7oMBV1i9A7kJ+89nOE1I+jxh/OM0S+9d+mEzbf7o1u whnjiY1dh2NPhEhPfRbcqH30jf+P9aIrZ7zaLrVvLYevY+rciY5rVrwNN33Bm/l8q024jWzd WXMW9Qf1Hs5HXp64dOL0OVGxy55t0zXbFgorlzw6rfJQfl/m2w2Pkx4osRRnJBpqMRcVJwIA jFlPCj0DAAA= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-30.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 12:52:49 -0000 --Apple-Mail=_25F78307-1FA6-4B83-BF07-9262F861ADDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Only change here was updating the JOSE references since they=E2=80=99re = now RFC=E2=80=99s. =E2=80=94 Justin > On May 28, 2015, at 8:40 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Dynamic Client Registration = Protocol > Authors : Justin Richer > Michael B. Jones > John Bradley > Maciej Machulak > Phil Hunt > Filename : draft-ietf-oauth-dyn-reg-30.txt > Pages : 43 > Date : 2015-05-28 >=20 > Abstract: > This specification defines mechanisms for dynamically registering > OAuth 2.0 clients with authorization servers. Registration requests > send a set of desired client metadata values to the authorization > server. The resulting registration responses return a client > identifier to use at the authorization server and the client = metadata > values registered for the client. The client can then use this > registration information to communicate with the authorization = server > using the OAuth 2.0 protocol. This specification also defines a set > of common client metadata fields and values for clients to use = during > registration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-30 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-30 >=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=_25F78307-1FA6-4B83-BF07-9262F861ADDF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVZw+bAAoJEDPAngkbd+w9sU4H/i7FUpiorFKYABw5IlDuvYM5 DiW7K3dP9/Kizwza3ecv8dmuA9uDSc+2OiNqSf8vhVCVF+zxv3HtyuSBf/cA55pe jO0lnNrhkWKp407h/PGGIn0Eo1a6cdE+h/+3kRCpEjvn5WlpwQI1BHcXyRzUuSjo 0Yoh222D+yz+W1pItFMdJ5u7/AeOfkIEtC3Iee73Jb0fZTqrJTa7wqP6JEYrAO5Y ny+HGpUgEfSmxVbz0Dqjd9ESf1ZPlgI4JyxjCOlZu7u/sab3ZgYwgvpqWc8ZMdci U36jyVrtt4dVQoVEPKr/128GpZvA42wZTwmXKyHLXRAJv8iFz21DxUCWX+iZxhY= =h4wA -----END PGP SIGNATURE----- --Apple-Mail=_25F78307-1FA6-4B83-BF07-9262F861ADDF-- From nobody Thu May 28 05:53:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B401A923D for ; Thu, 28 May 2015 05:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6TTczRJhcnq for ; Thu, 28 May 2015 05:53:36 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972851A9233 for ; Thu, 28 May 2015 05:53:17 -0700 (PDT) X-AuditID: 1209190d-f79526d000000ed5-b8-55670fbc4417 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id BA.CE.03797.CBF07655; Thu, 28 May 2015 08:53:16 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4SCrFXt023043 for ; Thu, 28 May 2015 08:53:16 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4SCqhox007471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 28 May 2015 08:53:15 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_01169B00-2069-4821-AEEA-62A32F8E7197"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <20150528124018.10774.72974.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 08:53:15 -0400 Message-Id: References: <20150528124018.10774.72974.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixCmqrbuHPz3UYPdPRYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+60ycwF50QrXrTXNTBOEOpi5OSQEDCRuLDlGTOELSZx4d56 ti5GLg4hgcVMEn9O3mSCcI4xSjz+fJEZwvnGJPH1+kp2kBZmgSmMEt+Wm4HYvAJ6Eo+ePgaL Cwt4Suyc/JoNYqyURNPrY4wgNpuAqsT0NS1MIDangJPE3uuPwGpYgOLbNu5ghphjJfHg+TKw eiEBR4mfP1+D2SIC6hJrzv8E6uUAmikr8XWr3ARGgVlIrpiF5AqIuLbEsoWvmSFsTYn93ctZ IGx5ie1v50DFLSUWz7wBFbeVuNW3gAnCtpN4NG0R6wJGjlWMsim5Vbq5iZk5xanJusXJiXl5 qUW6Rnq5mSV6qSmlmxjBsSDJu4Px3UGlQ4wCHIxKPLwV89JChVgTy4orcw8xSnIwKYny1nGk hwrxJeWnVGYkFmfEF5XmpBYfYlQB2vVow+oLjFIsefl5qUoivEe4gep4UxIrq1KL8mHKpDlY lMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwcvMBNQoWpaanVqRl5pQgpJk4OA8xSnDwAA1n AqnhLS5IzC3OTIfIn2JUlBLnjQRJCIAkMkrz4HphKewVozjQW8K8BSBVPMD0B9f9CmgwE9Bg s6MpIINLEhFSUg2Myud9xKt2/mVa1nFwzrwvxjfmuTw+GmGYJRJyiJv/yMNvjxYU/Jrya9m5 eSEL7Mv+L+WZZqvBtEtM/3ooq0HMid7ej5sV/jK0hxxf+Fa2tUFd9JzRs/mqdWsUfAWF3e9o xRiwTnHeFbRIknXnxXC2Lf/XVhlovr6W5f3Z5b5o6z07r7K5j26eUWIpzkg01GIuKk4EANvI Phw8AwAA Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 12:53:41 -0000 --Apple-Mail=_01169B00-2069-4821-AEEA-62A32F8E7197 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Likewise here: only change was updating the JOSE references to the = RFC=E2=80=99s. =E2=80=94 Justin > On May 28, 2015, at 8:40 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-09.txt > Pages : 16 > Date : 2015-05-28 >=20 > Abstract: > This specification defines a method for a protected resource to = query > an OAuth 2.0 authorization server to determine the active state of = an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information = about > the authorization context of the token from the authorization server > to the protected resource. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-introspection-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-09 >=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=_01169B00-2069-4821-AEEA-62A32F8E7197 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVZw+7AAoJEDPAngkbd+w9n94H+wbZoEJkSNLGJ1wBQb/O0F44 awGjYSZrjkqlw6Bp1kcWnDJXSqiGqy9hdM7uu7eEybiYHuhUdC4iHFxoJdrEPRY2 7DqB+Qd2xRcK70bklowjZyJwvvCWcUsLzG1409hBMq2zXeG0xYy6oR7kf4gWWEkz YBZHn07c/tJs6LoxUoLemi2p/HosSddsGmwf1kdYb0xZK4li/aUVufEqrqaNKFRR 1863GvoyGWiV4mP4vq+NrrO++B0j5SKWJ3FHbSJ6XlwnBK8UaTPteNUrk1m8z7On 5ILp5D1gS4kyjxbEvm52Tcvk1O2UBmTtulhAljgsGJvC6OJIWrVN7lWuYJsQqzo= =9Tqu -----END PGP SIGNATURE----- --Apple-Mail=_01169B00-2069-4821-AEEA-62A32F8E7197-- From nobody Thu May 28 09:24:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2BB1A90BD for ; Wed, 20 May 2015 13:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIbTO2AB2Eck for ; Wed, 20 May 2015 13:35:10 -0700 (PDT) Received: from mail.dynms.de (mail.dynms.de [85.25.184.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C17B1A90C6 for ; Wed, 20 May 2015 13:34:49 -0700 (PDT) Received: from [10.10.10.101] (chello084112032036.1.11.vie.surfer.at [84.112.32.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dynms.de (Postfix) with ESMTPSA id A4552546019F; Wed, 20 May 2015 22:34:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Patrick Gansterer In-Reply-To: <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com> Date: Wed, 20 May 2015 22:34:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com> To: David Waite X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 09:24:16 -0700 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 20:35:12 -0000 > On 20 May 2015, at 19:37, David Waite = wrote: >=20 >=20 >> On May 16, 2015, at 1:43 AM, Patrick Gansterer = wrote: >>=20 >> "OAuth 2.0 Dynamic Client Registration Protocol=E2=80=9D [1] is = nearly finished and provides the possibility to register additional = =E2=80=9CClient Metadata=E2=80=9D. >>=20 >> OAuth 2.0 does not define any matching algorithm for the = redirect_uris. The latest information on that topic I could find is [1], = which is 5 years old. Is there any more recent discussion about it? >>=20 >> I=E2=80=99d suggest to add an OPTIONAL = =E2=80=9Credirect_uris_matching_method=E2=80=9D client metadata. = Possible valid values could be: >> * =E2=80=9Cexact=E2=80=9D: The =E2=80=9Credirect_uri" provided in a = redirect-based flow must match exactly one of of the provided strings in = the =E2=80=9Credirect_uris=E2=80=9D array. >> * =E2=80=9Cprefix=E2=80=9D: The "redirect_uri" must begin with one of = the =E2=80=9Credirect_uris=E2=80=9D. (e.g. = "http://example.com/path/subpath=E2=80=9D would be valid with = [=E2=80=9Chttp://example.com/path/=E2=80=9C, = =E2=80=9Chttp://example.com/otherpath/=E2=80=9D]) >> * =E2=80=9Cregex=E2=80=9D: The provided =E2=80=9Credirect_uris=E2=80=9D= are threatened as regular expressions, which the =E2=80=9Credirect_uri=E2= =80=9D will be matched against. (e.g. = =E2=80=9Chttp://subdomain.example.com/path5/=E2=80=9C would be valid = with [=E2=80=9C^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/=E2=80=9C] >=20 > I don=E2=80=99t know if this is appropriate. For example, If a server = is unwilling to support arbitrary regex matching, how would a client = which required this be able to register dynamically? Or conversely: if a = client did not require regex matching, why would they request this from = a server? The point is not that a client can register at every server in that = case, but to know the (possible) (in)compatibility during registration = already. Otherwise a client can only do an authentication request (which = might not be possible when specific login-credentials are required) to = check if the required redirect_uri_matching_algorithm is supported by = the server. > If a client requests regex or prefix, it was built to rely on these to = work. If some set of servers choose not to support regex or prefix for = scope or security reasons, this hurts interoperability from the = perspective of dynamic registration. And we already have a workaround - = instead make your client rely on the state parameter. This is possible if there is a predefined list of redirect_uris. Imagine = a services where every user gets his/her own subdomain, which all have a = redirect_uri like https://user1.example.com/oauth/callback. With the current concept every subdomain must be listed to get the OAuth = stuff working on every subdomain. Now not every subdomain under example.com should be required to register = as a client, but only the TLD services hosted at example.com, = example.net and example.org, which all have their own subdomains like = https://user5.example.org. There is for sure the possibility to have a central =E2=80=9COAuth = gateway=E2=80=9D e.g. at https://oauth.example.com/, witch only need to = register one redirect_uri (e.g. = https://oauth.example.com/oauth/callback), but would be an additional = dependency for the =E2=80=9Cuser*=E2=80=9D-subdomains, since they have = to pass the OAuth request then to the =E2=80=9Cgateway". > A client doing code or implicit should specify exact return URLs in = their registration, and if they need to send the user someplace else = after authentication it should be represented to the client by their = state param. >=20 >> If not defined the server can choose any supported method, so we do = not break existing implementations. On the other side it allows an = client to make sure that a server supports a specific matching algorithm = required by the client. ATM a client has no possibility to know how a = server handles the redirect_uris. >=20 > The clients should be more than reasonably safe in assuming exact = matching works. If the server won=E2=80=99t support exact matching on = the redirect_uris supplied it should fail registration. Since not all OAuth services do exact matching AFAIK, this would be an = option to allow those services to tell their matching algorithm to the = client. =E2=80=94- Patrick= From nobody Fri May 29 01:42:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F741B2A98; Fri, 29 May 2015 01:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QZTYys00_I6; Fri, 29 May 2015 01:42:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D491B2A89; Fri, 29 May 2015 01:42:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529084249.8356.4145.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 01:42:49 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 08:42:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Request by JWS ver.1.0 for OAuth 2.0 Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-02.txt Pages : 9 Date : 2015-05-29 Abstract: The authorization request in OAuth 2.0 utilizes query parameter serialization. This specification defines the authorization request using JWT serialization. The request is sent through "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 29 01:47:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE81A87C6 for ; Fri, 29 May 2015 01:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnV4JTO8uEAX for ; Fri, 29 May 2015 01:47:47 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 A9E451A891C for ; Fri, 29 May 2015 01:47:47 -0700 (PDT) Received: by obew15 with SMTP id w15so52665976obe.1 for ; Fri, 29 May 2015 01:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=CKTfDqI/4h7I8Gj1qbFSlsVw8gf41YqQdUHYkorSd9g=; b=Ncr1/rTer0qlw4ipxWK1kd+wmTye5fKfG7iZ0HKXGMQRmbFRW8T/OERyO/f+/jplKs 6jQ1pXWilkuxfDAfpr/6HYtIANTUoCStEHiVrdl2Vh+pN+1E71dIqVVMWHFAsXdC0bNO kpXe4CUgRBXCDhA4a4ddtdhWFjsjVljiztzV6Lfl1NFN9eWhut4+yJAUFkTkD3o79y+k 7xBq6XtVs1IzakNKKTQSueOVXdEZeGQ16cURH72NvIu/IFcBX1TJXU3CHkvt0w2EMZmH aF2Z8mti+9r/6sDVDm1uYcXITeJ882pW/K/QUajZZmfO3YAbX+lbdEejD+3uaeQvXzFf jSbw== MIME-Version: 1.0 X-Received: by 10.202.205.149 with SMTP id d143mr5891613oig.84.1432889267064; Fri, 29 May 2015 01:47:47 -0700 (PDT) Sender: sakimura@gmail.com Received: by 10.60.219.39 with HTTP; Fri, 29 May 2015 01:47:47 -0700 (PDT) In-Reply-To: <20150529084249.8356.4145.idtracker@ietfa.amsl.com> References: <20150529084249.8356.4145.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 17:47:47 +0900 X-Google-Sender-Auth: rOD8a9BpgH09A4xshR2hcH9aO7c Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=001a1134fdc4c415b405173487b5 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 08:47:49 -0000 --001a1134fdc4c415b405173487b5 Content-Type: text/plain; charset=UTF-8 Dear OAuthers: I refreshed the draft replacing JWS, JWE, etc. with RFC numbers, now that they are RFCs. I also refreshed the JSON RFC number to RFC7159 from RFC4627. If you believe this is not what we want, please let me know. Best, Nat Sakimura Sr. Researcher Nomura Research Institute 2015-05-29 17:42 GMT+09:00 : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol Working Group > of the IETF. > > Title : Request by JWS ver.1.0 for OAuth 2.0 > Authors : Nat Sakimura > John Bradley > Filename : draft-ietf-oauth-jwsreq-02.txt > Pages : 9 > Date : 2015-05-29 > > Abstract: > The authorization request in OAuth 2.0 utilizes query parameter > serialization. This specification defines the authorization request > using JWT serialization. The request is sent through "request" > parameter or by reference through "request_uri" parameter that points > to the JWT, allowing the request to be optionally signed and > encrypted. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001a1134fdc4c415b405173487b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear OAuthers:=C2=A0

I refreshed the dr= aft replacing JWS, JWE, etc. with RFC numbers, now that they are RFCs.
= I also refreshed the JSON RFC number to RFC7159 from RFC4627. If you believ= e this is not what we want, please let me know.

Best,

Nat S= akimura
Sr. Researcher
Nomura Research Institute


2015-05-29 17:42 GMT+09:00 <internet-drafts@ietf.org>= ;:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Request by JWS ver.1.0 for OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-jwsreq-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-05-29

Abstract:
=C2=A0 =C2=A0The authorization request in OAuth 2.0 utilizes query paramete= r
=C2=A0 =C2=A0serialization.=C2=A0 This specification defines the authorizat= ion request
=C2=A0 =C2=A0using JWT serialization.=C2=A0 The request is sent through &qu= ot;request"
=C2=A0 =C2=A0parameter or by reference through "request_uri" para= meter that points
=C2=A0 =C2=A0to the JWT, allowing the request to be optionally signed and =C2=A0 =C2=A0encrypted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/<= br>
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-02

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


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

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

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



--
Nat Sakimura (=3Dnat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
--001a1134fdc4c415b405173487b5--